Estrategias IT contra la recesión
Escrito el 30 de Septiembre de 2008 a las 12:03
Creo que fue Alejandro Barrera el que reseñó en Twitter un interesante enlace en el que George F. Colony, de Forrrester Research, recopila una serie de interesantes estrategias para afrontar la próxima crisis desde el punto de vista de un director de IT. Paso a hacer un resumen, porque creo que merecen la pena:
- El outsourcing no es una “bala de plata” (de qué me sonará a mi esto
). Aprovecha la recesión para desarrollar las aptitudes internas. - Ya que vamos más lentos, aprovecha para mejorar los equipos. De hecho, aprovecha para traerte a ente buena que ha sido despedida de otros sitios.
- Evita el “Efecto Mar Muerto”. En el Mar Muerto entra agua, pero no sale, así que la mayoría del agua pura se evapora dejando los residuos. No dejes que tu mejor
genetegente se evapore durante una recesión. - Lo último en recortar debe ser el presupuesto de formación y desarrollo. Se trata de unos recursos críticos para el éxito tras la recesión.
- Aprovecha la recesión para tomar las decisiones duras: desembarazarte de proveedores redundantes o que no rinden y de empleados cuyo rendimiento no sea adecuado.
- Acelera la virtualización y otras medidas de eficiencia en tecnologías de la información y de negocio.
- Redobla los esfuerzos para añadir valor. Afila las métricas del ROI, publica los éxitos en IT/BT, reconoce y premia a los mejores trabajadores, intensifica la colaboración entre la tecnología y el negocio. Usa esta época para ser más visible al Director General, no menos.
- Contrata a los grandes MBA que se habrían ido a Wall Street en otras circunstancias
- Pide descuentos a tus proveedores y re-negocia los contratos siempre que sea posible
Aprovecho la ocasión que me brinda George al dejar inconcluso su decálogo para añadir:
10. adopta metodologías ágiles de desarrollo y mejora la gestión de proyectos en tu empresa”
![]()
Por lo demás, me parecen consejos para seguir no sólo en épocas de recesión, sino como principios de operación eficaz y eficiente de un área de IT, ¿No creeis?
Orcos a las puertas
Escrito el 19 de Abril de 2008 a las 10:52
Reflexionaba esta semana, junto con los jefes de proyecto de una de las empresas con las que estamos trabajando actualmente, respecto al problema histórico de comunicación entre las áreas de negocio y las áreas técnicas, tantas veces reflejadas, por ejemplo, en los chistes de Dilbert. Es un problema comprensible: las motivaciones muchas veces están enfrentadas (el área de negocio quiere más cosas en menos tiempo, el área de sistemas quiere más tiempo para dedicar a menos cosas) e incluso los lenguajes y el bagaje personal y profesional son tan difererentes que lo raro es que surja una buena comunicación.
Scrum, como sabéis, establece un artefacto (la pila de producto) que permite a la gente de negocio (Dueños de Producto) manejar a la gente técnica (Scrum Master y equipo). Sin embargo, uno de los problemas típicos que nos encontramos en las implantaciones de Scrum en las que trabajamos es el de involucrar a la gente de negocio en el proceso. La implantación de Scrum suele surgir por iniciativa de los técnicos, cosa rara si pensamos que la gente de negocio debería tener una formación y un foco más “humanista” y deberían haber sido los primeros que planteasen formas de colaborar y comunicarse con las áreas de producción (notese el matiz respecto a “áreas productivas”, que esas deberían ser todas, negocio y sistemas).
Al surgir desde el área técnica, las áreas de negocio tienden a veces a considerarlo “cosas de frikis” y pasar muy mucho del tema. Por eso nuestro enfoque de implantación conlleva muchas acciones dirigidas a las áreas de negocio. El objetivo final es que las áreas de negocio nombren un determinado número de Dueños de Producto que sean los que canalizacen y prioricen las peticiones de todos los interesados, clarificando al equipo lo que deben hacer en cada momento. Con eso evitamos también el bombardeo de peticiones “no oficiales” a las que típicamente se ven sometidos los equipos de desarrollo, peticiones cuya prioridad no está clara y que la mayor parte de las veces ni cuentan con una justificación de negocio sólida ni computan luego en la productividad del equipo, ya que se hacen “de tapadillo”.
Lamentablemente, el enfoque de envagelización y colaboración no siempre funciona, y los equipos de desarrollo se enfrentan a peticiones y negociaciones que les llueven por todas partes. Es como enfrentarse a un enemigo muy superior en número y recursos. ¿Y qué podemos hacer en una situación así?
Reflexionabamos sobre esto, como os decía, y tratando de explicar el enfoque que nosotros proponemos como siguiente nivel de presión hacia el cambio corporativo se me ocurrió la metáfora de los “orcos a las puertas”: La batalla del abismo de Helm.

En la batalla del abismo de helm, los humanos se parapetan en un fortaleza que cuenta con un único punto de acceso: un estrecho puente que obliga a los miles de orcos que los asedian a formar casi de uno en uno, con lo que en las puertas de la fortaleza se monta lo que los KODT llaman una “conga de la muerte”, una estrategia perfecta para lidiar con un enemigo muy superior en número y que ya fue utilizada por los 300 espartanos en el paso de las termópilas.
¿En qué consistiría la estrategia “orcos a las puertas”? En primer lugar, en blindar el área de sistemas. Kniberg lo describe muy bien en su libro. Esto se puede hacer a un nivel organizativo o discilplinario, aleccionando a todo el mundo para que no atiendan peticiones de ningún tipo que no vengan del Dueño de Producto de Sistemas, o incluso físicamente, co-alocando a todo el equipo y dejando pocas vías por las que los extraños puedan acceder y pulular. Incluso sentar al Dueño de Producto de Sistemas al lado de la puerta para que actue como guardián del área.
El segundo paso es precisamente ese: nombrar a un Dueño de Producto de Sistemas encargado de lidiar con los orc…Digooo…Con la gente de negocio. Nada fácil, os lo aseguro. En la mayoría de los casos una estraegia pasivo-agresiva como esta suele acabar en el despacho del CEO, pero a veces es precisamente esto lo que hace falta. Por eso es también muy importante preparar documentación sobre todos los intentos previos que se hayan hecho para que el área de negocio asuma la responsabilidad y la competencia que le toca sobre la definición y priorización de los proyectos. Eso nos permitirá justificar el movimiento defensivo.
A veces lo que ocurre es que el área de negocio está encantada con tener un interlocutor único en sistemas, y la estrategia “orcos a las puertas” se convierte en una mejor práctica corporativa. Pues estupendo. De hecho, no se vive tan mal en el abismo de Helm, siempre que uno tenga un puesto calentito, dos buenas pantallas TFT y unas cuantas herramientas de desarrollo… ![]()
Usando SugarCRM
Escrito el 24 de Enero de 2008 a las 11:00
Con demasiada frecuencia me encuentro con gente que tiene una fé excesiva en las herramientas. “Recomiéndame una herramienta para gestión de tiempo”, “dime una buena herramienta para gestionar proyectos”, “¿qué herramientas buenas hay para hacer Scrum?”. Como si la herramienta fuera a solucionar todos sus problemas. A ver si me explico: a lo largo de los años he ido construyéndome un buen set de herramientas de mecánica y bricolaje, pero el pasado fin de semana monté una estantería del Leroy y me quedó torcida. Por muy buenas que sean las herramientas, sigo siendo un manazas.
Y es que una herramienta es solo un complemento para hacer la vida más fácil y más productiva a aquel que ya sabe cómo deben hacerse las cosas. Posiblemente un maestro del bricolaje sea capaz de montar una estantería perfecta usando una moneda de euro como destornillador y una piedra como martillo. Lo contrario, un manazas con las mejores herramientas, no es aplicable.
Y sin embargo, cuando uno comienza a entender los rudimentos de la materia, una buena herramienta es un bien precioso. Eso me está pasando con SugarCRM. Hasta ahora había trasteado algunas veces con la herramienta en instalaciones para terceros, pero no le veía sentido para mi. De hecho, hace poco en una reunión de emprendedores del sector del software preguntaron cuántos usaban un CRM. La mayoría usaban Outlook como única herramienta, unos pocos usaban algún servicio on-line y otros pocos precisamente Sugar.
Eso me hizo pensar que, dado que el objetivo fundamental de este año es mejorar la gestión comercial, no sería mala idea comenzar a usar un CRM. Y allá que hemos ido con Sugar.
La primera impresión que puedo contaros es: ¿por qué leches no lo hicimos antes? . Hasta ahora, iban surgiendo nombres a los que llamar algún día, ofertas que se lanzaban y que nunca seguíamos (por vergüenza, dejadez o convencimiento de que no había nada que hacer), contactos a los que no manteníamos regularmente informados de nuestras operaciones… Porque al final todas esas cosas las vas dejando en algún rincón de tu cabeza, y el cerebro (que es muy jodío, el maldito) tiene tendencia a ir archivando bajo montones de escombros todas aquellas cosas que escapan a tu zona de confort. Y luego nos sentábamos a llorar “¡Que dificil es conseguir nuevos clientes!“.
Ahora es francamente complicado evadirse, porque cuando abres Sugar todo está ahi: las llamadas que tienes pendientes, las personas a las que hay que convertir en contactos, las oportunidades lanzadas con sus cifras de negocio y sus fechas límite. Después de cada reunión, se archivan los leads o nuevas tomas de contacto a realizar, las oportunidades surgidas, las tareas de seguimiento futuro…Y cuando empiezas a ver las cosas en forma de negocio potencial…Pues eso motiva. Obtienes además un rumbo bastante definido (el panel de inicio lista las tareas inconclusas, las llamadas pendientes, los contactos) y comienzas a obtener datos muy interesantes sobre cosas como de dónde vienen tus clientes (eventos, web, relaciones personales, clientes recurrentes), cuanto dinero realmente facturas de cada fuente, qué cuentas te están requeriendo más atención, el ratio de esfuerzo vs ventas, que tasa de éxito tienes según el perfil…
Huelga decir que toda esta información tiene un valor incalculable a la hora de planificar el crecimiento de la empresa, detectar áreas de mejora o escribir el bisnisplan.
Otras cosas que te permite Sugar es ir almacenando poco a poco la gigantesca (y cuasi-inutil, o al menos poco productiva) base de datos de contactos del Outlook de cada uno en una base de datos SQL común…Y cuando tienes una base de datos y un servidor de aplicaciones, las posibilidades son infinitas: mailings electrónicos por perfil de cliente, remesas de cartas comerciales, todo tipo de informes y estadísticas a medida, imprimir automáticamente los christmas navideños
…
No digo que muchas de estas cosas no se puedan hacer con Outlook y Office (combinar correpondencia), pero realmente no me apetece entrar en el debate “montar un ERP vs hacer las cosas en Excel”. Supongo que los sistemas empresariales es algo a lo que se llega con el tiempo y la madurez, y cada casa es un mundo: habrá empresas en las que merezca la pena y otras en las que no. Luís podría hablar mucho de esto, supongo.
Todavía tenemos que explorar muchas facetas: creación de campañas específicas y estudio de lo que funciona y lo que no, creación de dahslets personalizados con la información que realmente nos interesa, . Y por ser honestos, hay algunos bugs en la 5.0.0 que deberíamos ir puliendo poco a poco (problemas para editar las listas desplegables o para crear nuevos elementos desde ventanas pop-up…Cositas tontas, al fin y al cabo) y tenemos ciertos problemas de rendimiento corriendo sobre Xampp (posiblemente con la pila de Bitrock vaya mejor, y sobre una máquina dedicada Linux ya ni os cuento).
¿He mencionado que es GPL y gratuito?



