4 beneficios de la estandarización del hardware en las organizaciones

De entrada, la estandarización aporta un beneficio claro: permite realizar la misma actividad de la misma forma cada vez.

Estandarización de hardware

En el ámbito de los sistemas de información muchas empresas, especialmente de tamaño pequeño y mediano, sufren la falta de estandarización del hardware que soporta su negocio.

Esta situación se da cuando no hay un departamento de sistemas de información que, de forma centralizada y homogénea, establezca una política o unos criterios de adquisición de hardware.

Un síntoma de la falta de estandarización de hardware es la gran diversidad de marcas y fabricantes en los PCs de los usuarios de la organización. La situación se complica aún más cuando se juntan en un departamento ordenadores de diferentes (y a veces muy diversas) antigüedades. Lo mismo ocurre con frecuencia con las impresoras: muchas empresas disponen de un bonito “jardín” con impresoras en casi cada mesa de usuario y casi cada una de ellas de un fabricante o modelo diferente.

Resultados negativos de esta situación

– Tiempos de espera innecesariamente largos cuando se produce un fallo.

– Problemas y sobrecoste en la gestión de los recambios (ya sea de piezas para los PC como de toners para las impresoras).

Almacén de recambios de hardware

Almacén de recambios de hardware (cortesía de booleancomando bajo licencia CC BY-NC-SA 2.0)

Una situación similar se puede llegar a dar en el CPD (Centro de Proceso de Datos). Como consecuencia de procesos de adquisición o fusión con otras organizaciones o porque el departamento de Compras ha encontrado una determinada “ganga” que le ha ofrecido un proveedor: variedad de servidores de diversos fabricantes y modelos, un “jardín” de switches, …

En este caso los resultados son también negativos:

– Problemas y sobrecoste en la gestión de los recambios

– Sobrecoste y mayor complejidad en la gestión de acuerdos de mantenimiento de hardware con los fabricantes

– Necesidad de mayor conocimiento (más diverso) dentro de los miembros del departamento de sistemas de información para poder gestionar un parque amplio.

Posibles vías de solución

1. Definir modelos estándar de PC según el tipo de usuario, limitando el catálogo de PCs a 2 o 3 dentro de toda la organización.

2. Realizar compras de PCs de forma regular y programada, sin esperar a que los ordenadores se vayan “muriendo”.

3. Dejar de trabajar con una impresoras para cada usuario (o compartida para grupos de usuarios muy reducidos) y pasar a trabajar con grandes impresoras en red y en modo de pago por uso.

Beneficios de la estandarización de hardware

1. Las compras “en bloque” permiten conseguir descuentos con los proveedores y ayudan a controlar mucho mejor los períodos de garantía de las máquinas.

2. Limitar el parque de PCs a 2 o 3 modelos distintos facilita mucho la labor de los responsables de su mantenimiento: por un lado limita el conocimiento de modelos a controlar y sus particularidades y por otro permite tener un reducido stock de repuestos que cubre todo el parque.

3. La limitación de modelos también favorece la resolución rápida de averías, dado que se dispone de repuestos y que se tiene mayor conocimiento de las particularidades de los 2 o 3 modelos a mantener. Esto es bueno porque limita los tiempos de caída de los servicios.

4. La estandarización de las impresoras y el pago por uso permiten a los departamentos de sistemas (o compras según el caso) olvidarse del mantenimiento y de la gestión de los toners (y su reciclaje).

En una de las empresas en las que he trabajado conseguimos poner en marcha este proceso, realizando una compra anual de PCs y renovando todo el parque cada 4 años (una cuarta parte cada año). Logramos descuentos importantes en las compras y pudimos empezar a gestionar correctamente las garantías de los fabricantes, entre otros beneficios ya mencionados.

La sustitución de más de una veintena de pequeñas impresoras “personales” por 3 impresoras en red permitió un importante ahorro de costes (que además, si así se desea, se pueden llegar a imputar por usuario) y minimizar los tiempos sin servicio.

¿Qué hacéis en vuestras organizaciones? ¿Seguís este tipo de prácticas? ¿Qué dificultades os encontráis?

4 beneficios de la estandarización del hardware en las organizaciones

Cloud computing: marketing e incertidumbre

La pasada semana he asistido a un evento sobre cloud computing organizado por un conocido grupo de comunicación en el sector de las TIC. Este es un tema que me interesa especialmente porque creo que es el futuro. Sin embargo, siendo un concepto muy tratado, cada organización puede aproximarse a él de formas muy diversas.

La nube: el concepto

El cloud computing se basa en la facilidad de acceso a sitios remotos que hoy en día proporciona internet. El concepto engloba la provisión de aplicaciones, datos, almacenamiento e infraestructuras de forma transparente para el usuario, que no precisa conocer ni la configuración de los sistemas ni su ubicación física.

, via Wikimedia Commons”]

La nube proporciona transparencia y flexibilidad al usuario final. Eso es bueno para “organizaciones líquidas”, concepto que he conocido a través de Jaime García Cantero (@jaimegcantero), que es en lo que se están convirtiendo nuestras empresas progresivamente: con límites y formas cambiantes, cada vez menos definidos y en constate trasformación.

Como he apuntado antes, no hay una única forma de consumir el cloud computing. Cada organización deberá adaptarlo a sus propias necesidades y circunstancias: habrá quien contrate aplicaciones como servicio, quien busque sistemas de almacenamiento ubicuos y flexibles, quien desee mantener servicios como el correo electrónico bajo su control directo o quien lo contrate como servicio a grandes proveedores como Google, quien virtualice, quien comparta servidores con otras organizaciones y quien trabaje con su nube privada.

, via Wikimedia Commons”]

En cualquier caso, creo que la mejor forma de aproximarse al tema es analizando servicio a servicio todos los que son prestados por el departamento de TIC, considerando sus necesidades de disponibilidad, su criticidad, las normativas legales que en cada caso apliquen, … y buscando un buen socio que nos acompañe en todo el proceso, asesorándonos sobre los mejores proveedores y la mejor estrategia a seguir.

Y es que el mercado de la nube está todavía poco maduro, en pleno crecimiento, como lo demuestra que el número y pelaje de los proveedores de cloud computing vaya en aumento día a día. Hay operadoras de telecomunicaciones, proveedores tradicionales de servicios de housing y hosting, grandes corporaciones internacionales, …

, via Wikimedia Commons”]

Y también hay mucho marketing. Se habla mucho de la nube pero, como pudimos comprobar en el evento al que hacía referencia al principio de la entrada, las empresas todavía la usan poco. No ocurre así con los particulares, ya muy habituados a gmail, dropbox, spotify, etc.

Incógnitas

¿Cómo evolucionará este mercado? ¿Quienes acabarán siendo los players principales? ¿Cómo se acabará segmentando? ¿Qué beneficios reales acabarán obteniendo las organizaciones? ¿Será suficientemente seguro?

Y yendo más hacia las afectaciones concretas de un departamento de TIC, ¿cómo afectará la nube a nuestra base instalada (nuestros activos)? ¿seremos capaces de convertir aplicaciones (cloud) estándar en aplicaciones de negocio (personalizadas)?

Y, en particular, los CIO y/o responsables del área de TIC, ¿serán capaces de transformarse de gestores de activos en gestores de servicios?

Conclusiones

En conclusión; mi impresión es que por ahora hay mucho marketing y demasiadas cuestiones abiertas.  Sin embargo, creo que es un camino que nuestros departamentos de TIC deberán transitar si nuestras organizaciones quieren seguir siendo competitivas. Habrá que ir poco a poco, dando pasos lentos pero firmes y tratando de ir resolviendo incógnitas por el camino.

Cloud computing: marketing e incertidumbre

Revisión de la arquitectura de aplicaciones

Para mucha gente, entre la que me encuentro, las vacaciones son un buen momento para reflexionar y dedicar tiempo a pensar en aquellos temas a los que el día a día no le deja tiempo. También es importante usarlas para desconectar.

En estas últimas semanas de agosto, sin entradas en el blog, he estado dedicando algunos ratos a pensar en la arquitectura de aplicaciones a la que me gustaría llegar en mi empresa en 1 o 2 años. En septiembre la empezaré a discutir con mi equipo.

Las capas de la arquitectura

La infraestructura de aplicaciones de una organización, esté estructurada o no, escrita en un documento o no, se organiza en 4 capas básicas, según el esquema siguiente:

Arquitectura de aplicaciones

De estas 4 capas, en esta entrada me interesan 2, la arquitectura de aplicaciones y la arquitectura de la información. La segunda se apoya en la primera, según se intuye en la figura.

La arquitectura de aplicaciones es básicamente lo que entenderíamos como el catálogo de aplicaciones con sus interfaces.

La arquitectura de información se basa en los flujos de información, las relaciones entre entidades de datos así como las herramientas y actividades que el negocio (capa superior) impone.

La arquitectura actual y la arquitectura objetivo

Para definir la arquitectura de aplicaciones yo utilizo básicamente 3 documentos:

  • Un inventario de aplicaciones por área funcional, estructurada en base a aplicaciones de planificación, de operaciones y de análisis.
  • Una descripción de la forma como estas aplicaciones se comunican entre ellas y con otros sistemas internos y externos.
  • Una descripción de cada aplicación y su razón de ser, incluyendo:
    • sistema
    • nombre
    • funcionalidades
    • plataforma en que se sustenta, …

Periódicamente es conveniente revisar la arquitectura de aplicaciones existente en base a:

  • cómo le afectarán los proyectos en curso o futuros que la organización tiene previstos.
  • qué aplicaciones se encuentran ya en la etapa final de su ciclo de vida

Estrategia y Plan de Migración

A partir de aquí se puede definir una estrategia de aplicaciones que nos marque qué aplicaciones cabe retirar, cuales deben ser actualizadas y dedicarles más recursos, en cuales debe ajustarse el nivel de servicio y los recursos empleados y en cuales, simplemente debemos seguir como hasta ahora.

A partir de la estrategia anterior ya estamos en condiciones de diseñar la arquitectura de aplicaciones objetivo (con los mismos documentos que hemos utilizado para definir la arquitectura actual).

Para llegar a esta imagen futura (que puede ser a 1, 2, o incluso 3 años vista) deberemos establecer un Plan de Migración, obtener recursos, presupuesto, … pero eso ya es otro tema.

¿Qué opinas? ¿utilizas un sistema similar en tu organización? ¿cómo documentas la arquitectura de aplicaciones?

Revisión de la arquitectura de aplicaciones

Primero una buena base

Recuerdo que cuando estudiaba Planificación de Sistemas de Información en el MGTI de La Salle nuestro profesor nos preguntaba con frecuencia si queríamos que nuestro departamento de TI fuera operativo o estratégico.

Su intención era convencernos de que el departamento TIC ideal debe ser capaz de ayudar a elaborar la estrategia corporativa y, sobretodo, debe ser un facilitador para llevarla a cabo. Debe existir un alineamiento entre el departamento de sistemas de información y la estrategia corporativa.

Hasta aquí todo bien. Este afán de ser estratégico es un objetivo ambicioso para cualquier departamento de TI. Es lo que nos gustaría ser de mayores. Pero primero lo primero.

El departamento debe ser capaz de cubrir primero las necesidades básicas de la organización en materia de TIC antes de intentar liderar y marcar la estrategia.

La primera cualidad del  responsable de sistemas, a mi entender, debe ser el pragmatismo. Es básico conseguir una infraestructura que asegure las operaciones y el día a día de la organización sin problemas. Cuando el departamento deja de pasarse el día apagando fuegos entonces puede empezar a dedicarse a tareas más elevadas como mejorar su conocimiento del negocio o mantenerse al día de los nuevos desarrollos tecnológicos.

Lo básico no es tan “interesante” como la definición de nuevos proyectos o probar nuevas tecnologías pero para un responsable de sistemas va a ser difícil convencer a la Dirección de la empresa de que implante un sistema de Business Intelligence si el departamento tiene dificultades para proporcionar a la organización un servicio de correo electrónico con un nivel de disponibilidad mínimamente razonable.

Pirámide de Maslow
Interpretación de la jerarquía de necesidades de Maslow

Es lo que John Baschab y Jon Piot definen como la pirámide de Maslow de las TIC en su libro The Executive’s Guide to Information Technology. Sin cubrir los niveles inferiores de la pirámide no podemos aspirar a la cumbre.

Y eso es algo que se olvida con frecuencia en muchos departamentos de TI. ¿Estáis de acuerdo?

Primero una buena base

Indicadores para el sistema de gestión

Hace unas semanas participé en un taller de calidad en RTM.

El objetivo era mejorar la efectividad de los sistemas de gestión de la calidad implantados en las empresas de los asistentes.  Tratamos muchos temas pero a mi me interesaba especialmente mejorar la definición de indicadores y objetivos.

Un sistema de gestión de la calidad como ISO 9001 está basado en procesos. Para conocer el nivel de madurez de un proceso es preciso definir indicadores representativos y medirlos. Recordemos la famosa cita de Lord Kelvin “Lo que no se define no se puede medir, lo que no se mide no se puede mejorar y lo que no se mejora se degrada siempre”.

Algunas de las conclusiones que extraje del taller, en relación con la definición de indicadores fueron:

  • deben ser representativos del proceso
  • deben ser fáciles de calcular
  • se debe definir la frecuencia con la que se calculan
  • deben establecerse unos objetivos en relación con cada indicador
  • tras su cálculo con la frecuencia prevista, deben definirse acciones que corrijan la situación en caso de estar fuera de los objetivos.

Pero, ¿cómo se relacionan estos indicadores, más bien operativos, con los objetivos estratégicos de la compañía? Hasta ahora sólo estamos midiendo para conocer el estado de nuestros procesos de negocio pero ésto no sirve de mucho si no somos capaces de hacer que lo que medimos nos permita conocer lo cerca o lejos que estamos de nuestros objetivos corporativos.

Por ejemplo, el nº de visitas realizadas al mes por un vendedor puede ser un indicador que mida el proceso comercial pero no nos garantiza el cumplimiento de un determinado objetivo de facturación que puede ser estratégico.

En ocasiones, se puede dar la circunstancia de que algunos de los indicadores definidos para nuestros procesos de negocio ya nos permitan conocer si nos estamos acercando o no a nuestros objetivos estratégicos. Pero, como hemos visto, puede que no siempre sirvan.

En este último caso será preciso definir indicadores adicionales específicos para medir lo cerca o lejos que estamos de nuestros objetivos corporativos. Como resultado tendremos un cuadro de mando con indicadores más o menos operativos, para el día a día, y con otros más estratégicos.

cuadro de mando - bajo licencia cc de http://www.flickr.com/photos/jdhancock/

Un último comentario: puede llevar varios años conseguir definir un buen cuadro de mando, con los indicadores adecuados y que nos sea útil. Se trata, creo, de un proceso de ensayo y error. De hecho, es de nuestros errores de lo que más podemos aprender.

¿Qué opinión tienes sobre estas conclusiones? ¿qué tipo de indicadores utilizas? ¿cómo los relacionas con los objetivos estratégicos de la organización? Compartiendo nos enriquecemos; espero vuestras aportaciones.

Indicadores para el sistema de gestión

Buenos propósitos para 2011

En estas fechas navideñas es típico repasar cómo nos ha ido el año; si hemos conseguido o no lo que nos habíamos propuesto y preparar un listado de buenos propósitos para el año próximo.

Creo que es bueno tener objetivos, a mi me sirven. Siempre que se hayan planteado bien.

Voy a compartir en este post algunos de mis objetivos a nivel profesional para 2011. Espero que el hecho de compartirlos públicamente me ayude a comprometerme más con ellos :

1. Certificarme como PMP.

Éste creo que es mi objetivo más ambicioso. Me estoy preparando por mi cuenta y tengo que hacer todavía la solicitud al PMI pero confío en certificarme dentro de 2011.

2. Mejorar mi formación en comercio electrónico y business intelligence (BI). Tengo especial interés en el BI porque lo veo como un punto de convergencia entre las dos áreas a las que me dedico profesionalmente; TIC y Gestión de la Calidad.

En mis últimos años en contacto con la dirección de mi empresa he observado la importancia de disponer de una buen Cuadro de Mando Integral. No basta con tener mucha información, hay que saber organizarla y gestionarla adecuadamente para poder tomar decisiones en base a ella.

La combinación de tecnología y aplicación de la estrategia de negocio me atrae especialmente.

3. Gestionar con éxito el que probablemente será el proyecto más importante de mi departamento (TIC) en 2011: la migración de nuestro ERP.

Este proyecto va a tener gran visibilidad en nuestra organización y quiero utilizar las mejores prácticas para llevarlo a cabo con éxito. Además, espero que me sirva como aplicación práctica del objetivo número 1.

Por supuesto hay muchos otros asuntos importantes en los que quiero mejorar profesionalmente, como lograr incrementar el aprovechamiento del sistema de gestión de la calidad que tenemos implantado,  pero creo que conviene tener un número adecuado de objetivos que nos permitan centrarnos y lograr su consecución.

Bueno, ya están expuestos. Son específicos, medibles, alcanzables (aunque retadores), realistas y están acotados en el tiempo.

Definiendo objetivos "smart" (en inglés)

A ver qué balance puedo hacer dentro de un año.

Hace unos días, uno de mis proveedores me envió la siguiente cita en su felicitación navideña: “que los problemas de año próximo duren tanto como los buenos propósitos navideños”. Tengo que reconocer que tiene un punto de realismo pero espero que no se dé en mi caso.

 

Buenos propósitos para 2011

Sobre el uso de software libre (FOSS) en la empresa

Hace unos días me encontré una propuesta de discusión en uno de los foros de LinkedIn en los que participo. Por un momento pensé, como luego ha sugerido uno de los otros participantes, que se trataba de una provocación, un troll. La propuesta era Open Source is ideal if you can support it y planteaba las supuestas dificultades de mantener plataformas de software libre en la empresa, frente a las facilidades de las opciones propietarias.

Hace varios años que en la empresa para la que trabajo pusimos en marcha una infraestructura con una importante presencia del software libre.  No me arrepiento. No creo que sea una solución universal, se debe estudiar cada empresa, su cultura, su estrategia (corporativa y de TIC que, dicho sea de paso, deberían estar siempre alineadas), pero creo que es una vía a estudiar en cualquier caso.

Análisis completo.

Mi opinión es que el software libre (FOSS – Free and Open Source Software) debe considerarse como una más de las opciones y analizarse con sus ventajas e inconvenientes cuando se aborda la búsqueda de una plataforma tecnológica que soporte un nuevo servicio.

Para que el análisis sea correcto debe abarcar el coste total de propiedad (TCO) de la plataforma durante todo su ciclo de vida. Es cierto que en el mundo del software libre la mayoría de opciones utilizan licencias de uso gratuitas, pero esa es sólo una parte del coste de las aplicaciones y no siempre la más importante. Hay que tener en cuenta los costes de mantenimiento de hardware y software, la formación, el servicio de soporte, etc.

En el caso de aplicaciones consideradas mission critical considero fundamental disponer de un soporte adecuado, independientemente de que estén basadas en software libre o propietario.

Es cierto que el mantenimiento de aplicaciones basadas en software libre acostumbra a precisar personal de alto nivel técnico frente a algunas opciones propietarias, como las basadas en la plataforma de Microsoft, habitualmente más fáciles de gestionar.

No obstante, cada vez es más fácil conseguir este tipo de soporte incluso para pymes. Se puede optar por internalizar esta función pero en nuestro pais hay ya un buen tejido de empresas de apoyo especializadas en software libre, muy profesionales y que pueden aportar soluciones con garantías para soportar cualquier tipo de servicio corporativo.

El software libre tiene su mercado, es la plataforma líder en servidores web y tiene gran importancia en muchas otras áreas como seguridadCMSBIERPCRM, etc. Probablemente, su punto más débil se encuentra en el mundo del escritorio donde, a pesar de los esfuerzos realizados por Ubuntu, todavía mantiene un estigma de dificultad de uso entre el común de los usuarios de sistemas informáticos.

Ventajas y desventajas del software libre

Sin ánimo de ser exhaustivo,

Ventajas.

Precio. En general, los costes de licencia son nulos o muy inferiores a los de opciones propietarias.

Personalización. Disponer del código fuente permite adaptar al máximo la aplicación a las necesidades del usuario.

Seguridad. La publicación del código fuente es una garantía de seguridad. La fortaleza de una solución de seguridad no debe estar en el desconocimiento de claves y código sino en la potencia de éste último.

Desventajas.

Mayor complejidad de uso y configuración. Ésto es una generalización, pero creo que suele ser cierta.

Dificultad (en algunos casos) de complementarla con otras opciones (propietarias). Por ejemplo, los servidores BES de Blackberry (BB) sólo se entienden con servidores de correo Exchange de Microsoft. Cualquier solución de correo basada en Linux limita las prestaciones del servicio BB, salvo el uso de Zimbra Desktop con un conector apropiado.

Buscar tu propia solución.

En mi empresa utilizamos plataformas basadas  en software libre en algunos servidores corporativos pero no de forma sistemática y tampoco en los escritorios de los usuarios. Hemos procurado buscar la mejor opción para cada función, teniendo en cuenta sus interrelaciones y en nuestro caso el resultado ha sido un sistema mixto basado en plataformas Linux y Microsoft.

En cualquier caso, como cualquier otra opción, el software libre debe ser considerado como posible solución para soportar cualquier tipo de servicio. Al igual que con opciones propietarias, debemos asegurarnos siempre de disponer de un buen soporte y de gestionarlo adecuadamente para no quedarnos en situación de dependencia de nuestro proveedor, utilizando las mejores prácticas que aseguren una razonable transición de servicio. Aunque se decida externalizar el mantenimiento siempre es muy positivo disponer de personal propio con conocimiento suficiente para hablar de tú a tú con el proveedor de este servicio y mantener el control del mismo (como recomienda el llamado principio de agencia de ITIL).

 

Sobre el uso de software libre (FOSS) en la empresa