¿Sigue importando la IT?

Se cumplen nueve años de la publicación en la revista de negocios de Harvard del artículo de Nick Carr “Does IT Matter?”. Carr, un periodista avispado (sea dicho con respeto hacia los periodistas y las avispas), proponía la idea de que las TIC se habían convertido en “commodities” (servicios públicos de primera necesidad y bajo precio, como el agua, el gas o la electricidad), fáciles de copiar y de extender, mientras seguían (en aquella época) comprándose y pagándose como artículos de lujo. En su opinión, la informática (como el agua o la electricidad, de nuevo) es más una fuente de riesgo operativo (una caída de sus sistemas paraliza a cualquier empresa) que de ventaja competitiva (existe más capacidad y funcionalidad que las necesidades de negocio que se necesitan cubrir, individual y globalmente). En consecuencia, Carr animaba a las empresas a recortar costes en IT, mejorar la utilización de la capacidad actual, externalizar su gestión a especialistas y retrasar nuevas invesiones.

El pobre Carr no sabía mucho de informática ni de empresa pero tuvo la fortuna de acertar en el momento (la crisis económica, financiera, organizativa y de creatividad) que siguió a la burbuja tecnológica de 2001 y en el estado psicológico, de escepticismo y hastío que vivían los ejecutivos e inversores. Durante los años 90, la inversión TIC en Estados Unidos había llegado a representar un tercio del total de inversiones de las empresas en cualquier clase de activos y las promesas de mejora de productividad, valor de mercado o ventaja sobre la competencia, a juicio de muchos, no se habían cumplido.

El artículo de Carr fue una sacudida e hizo daño, la verdad, pero también provocó una formidable reacción de la comunidad científica, de los practicantes y de todo el (poderoso) sector de fabricantes y proveedores de servicios TIC. Hasta Bill Joy, cofundador de Sun, se preguntaba en una intervención en el Foro Económico de Davos de 2003: “¿Y si resulta que la gente (consumidores y empresas) ya ha comprado todas las cosas (productos y servicios informáticos) que necesita?”.

Entre las réplicas y contrarréplicas pueden encontrarse algunas de las páginas más doradas de la literatura de dirección de los sistemas de información (Management of Information Systems), como los artículos de Seely Brown (ex director del laboratorio Xerox en sus mejores años) con John Hagel III o los decanos McFarlan y Nolan (de la Harvard Business School).

La crítica más inteligente no dejaba de aceptar los daños que había producido el gasto desordenado e irracional en la implantación de grandes sistemas en las empresas (la burbuja de los ERP y el año 2000) o en la construcción de grandes infraestructuras (como los sistemas submarinos de fibra óptica), las promesas de vendedores sin escrúpulos, la credulidad de los ejecutivos y la volatilidad de las inversiones que cayeron cuando se demostró que no tenían detrás clientes, beneficios ni un modelo de negocio sostenible. Reconocían también la comoditización de algunas partes de la informática (como la gestión de infraestructura, el mantenimiento de aplicaciones o ciertos paquetes de empresa de uso general). Reconocían, en definitiva, que a lo largo de los años, y a medida que había aumentado y se había generalizado el consumo de las tecnologías, la importancia de las TIC como fuente de ventaja competitiva estaba disminuyendo (como ocurre con cualquier otra cosa, por lo demás).

Sin embargo, el argumento central y el más útil para nosotros, es que las tecnologías de la información y las comunicaciones, consideradas aisladamente de su uso social y empresarial, ni aportan ni dejan de aportar nada y que, en realidad, lo que crea valor y ventaja competitiva, lo que importa, es la manera en que las empresas, los individuos y los directivos son capaces de utilizarlas, implantarlas y explotarlas. Los avances en las tecnologías de la información proporcionan (y han seguido proporcionando) oportunidades sin precedentes y multiplican (y han seguido multiplicando) otras que ya teníamos, pero depende de nosotros capturar sus beneficios.

Seguiremos en otra entrada, si resulta de interés, desgranando los argumentos de la polémica y lo que ha aportado la investigación empírica al final del día sobre todo esto.

Nota:

El artículo original de Nick Carr (HBR, Mayo 2003) y las réplicas y contrarréplicas más interesantes se encuentran en una edición especial muy recomendable: Harvard Business Review at Large (Reprint R0305B).

Publicado en Profesión | Etiquetado , , , | Deja un comentario

Steve Jobs: La biografía

Antes de comenzar, déjenme que diga que no soy sospechoso de ser amigo de Apple. Y aunque tengo un iPod Shuffle y el primer ordenador con el que empecé a programar (y me enamoré de éste, nuesto ámbito) era un Apple II :_) , nunca me ha gustado la estrategia del señor Jobs. He sido, soy y seré muy crítico con ella, aunque reconozco que Apple le da mil vueltas al resto de compañías en lo que se refiere a la experiencia de usuario, entre otras cosas.

Aun así, como informático, creo que debía dar a la biografía de Steve como mínimo una oportunidad. El libro es bastante largo (más de 800 páginas), por lo que no tenía claro que pasase del primer capítulo. Con esta actitud, comencé a leer. Y debo decir que, sorprendentemente para mi, lo he acabado, y lo que es más, lo recomiendo encarecidamente. Léanlo. De verdad.

Antes de entrar en el personaje, déjenme decir que sí que es cierto que en ciertos momentos parece un poco una apología de la marca que creó. Pero realmente, yo creo que esto viene dado por las fuertes convicciones de Jobs y su capacidad de concentración en la línea seguida. Eso lleva al libro a repetir constantemente sus mantras sobre cómo debe ser una empresa y cómo deben crearse los productos.

El texto muestra a una persona que en mi opinión tiene aquello que suelen recopilar los genios: por un lado una visión y unas capacidades fuera de lo común. En el caso de Jobs, para entender, a priori, qué es lo que necesita la gente y cómo debe ser. Y por otro lado, una incapacidad para tratar otros aspectos de la vida: en su caso, a las personas: falta de empatía o asertividad, etc. Todo esto, lleva a Jobs a tener una vida profesional espectacular, en la que a parte de algunos fracasos (siempre bien valorados en el mundo anglosajón y muy mal en el nuesto, por desgracia), su legado es espectacular. A parte de todos los productos de Apple que ya conocemos y que no voy a enumerar, su irrupción en Pixar fue determinante. Este señor cambió el mundo. Sí, ya se que no estaba solo. Y, de hecho, creo que en el libro se hace justicia (nunca plena, seguro) a algunos de los que le acompañaron en el camino.

Cabe decir que Jobs nunca llegó a leer el libro, ya que uno de las condiciones que puso al escritor (Walter Isaacson) fue no controlar su desarrollo. Evidentemente, él fue la mayor fuente de información, pero a parte de esto, está muy bien documentado con opiniones de amigos y enemigos. Y créanme, a mi no me gustaría que se explicasen de mi persona ciertas cosas que se dicen de Jobs en la biografía. De hecho, y sin hacer ningún spoiler (porque creo que todos sabemos cómo acaba el libro), en su lecho de muerte, Jobs le pregunta a Isaacson si se enfadará con él cuando lea el libro, a lo que el autor responde que, sin duda, leerá cosas que no le gustarán. Es por esto que Jobs le promete que, para evitarlo, no lo leerá hasta que haya pasado un año de su publicación. Por desgracia, esto no fue posible.

Descanse en paz uno de los genios más grandes que ha dado nuestro ámbito. Lean el libro. Conocerán a una persona especial y se darán un paseo por Silicon Valley, conocerán al señor Hewlett y al señor Packard, al bueno de Woz, que implementaba las ideas que compartía con Jobs y que siempre quiso un sistema abierto, en contraposición a lo que quería Steve. Se sorprenderan con la gente del Xerox PARC, que inventaron casi todo lo inventable y no fueron capaces de llevarlo a la gente. Verán lo importante que fue el protagonista para Pixar, y la industria de la animación digital, así como para una Disney que en aquellos años se comenzaba a tambalear. Entenderán un poco más la relación de amor-odio entre Jobs y Bill Gates, entre Apple y Microsoft. Conocerán al Steve zen, vegetariano, ayunador, descalzo, con una más bien justa higiene personal, enfermo, manipulador, maniático, líder, etc.

En fin, descanse en paz, y por tercera y última vez en esta entrada, permítanme que les diga: Léanlo. Habrá cosas con las que no estén de acuerdo, cosas que no les gusten y otras que les sorprendan, pero no creo que se aburran ni que se arrepientan.

Publicado en Recurso | Etiquetado , , | 4 comentarios

El Máster en Ingeniería Informática en el EEES

En España, el Espacio Europeo de Educación Superior organiza las enseñanzas universitarias oficiales en dos niveles: grado (de 240 ECTS, 4 años a tiempo completo)  y máster (entre 60 y 120 ECTS, entre 1 y 2 años a tiempo completo). Si en su día ya repasamos el papel y la estructura del Grado, en esta entrada vamos a revisar cómo es la formación oficial de Máster en Ingeniería Informática.

La primera clave para entender el Máster son las “fichas” publicadas en el BOE. Recordemos que los títulos de las profesiones reguladas deben cumplir un conjunto de requisitos para que sus titulados pueden acceder al ejercicio de la profesión. Estos requisitos incluyen: las competencias a alcanzar en el programa, los módulos que deben estructurar el programa y los creditajes mínimos para cada grupo de competencias o área de conocimiento. De esta forma, aunque dos títulos provengan de universidades diferentes, garantizarán todos los requisitos para el ejercicio profesional.

Aunque la regulación de la ingeniería informática sigue siendo un tema espinoso, el Consejo de Universidades finalmente publicó unas fichas para la Ingeniería Informática a petición de la CODDII. Estas fichas incluyen recomendaciones para el diseño de los Grados y Másters en Ingeniería Informática, de forma que:

  • Define el itinerario formativo completo, a nivel de Grado y Máster.
  • Harmoniza los títulos de las diferentes universidades, tanto a nivel de Grado como de Máster.

Los títulos que sigan las recomendaciones de estas fichas permiten acceder al ejercicio de la profesión de Ingeniero Informática. Según estas recomendaciones, un título de Máster en Ingeniería Informática debe incluir al menos los siguientes tres módulos:

  • Dirección y Gestión (mínimo 12 ECTS): Este módulo aporta competencias de dirección y gestión de equipos, proyectos y organizaciones del ámbito TIC. Este módulo juega un papel muy relevante ya que, al tratarse de una formación de Máster, los estudiantes tendrán un perfil senior que está en posición de asumir responsabilidades de liderazgo.
  • Tecnologías Informáticas (mínimo 48 ECTS): Este módulo desarrolla las competencias tecnológicas en diferentes ámbitos (seguridad, sistemas de información, sistemas inteligentes, etc.), ampliando los conocimientos y habilidades adquiridas dentro del Grado.
  • Trabajo Final de Máster (entre 6 y 30 ECTS): Por último, el trabajo final permite poner en práctica las competencias adquiridas en un proyecto individual en un campo de la Ingeniería Informática.

Sobre la duración del máster, podéis ver que el creditaje mínimo de un Máster de Ingeniería Informática es de 66 ECTS, algo más de un año a tiempo completo. Muchas universidades presenciales han optado por ofrecer Másteres de 90 ECTS (3 semestres a tiempo completo), donde 30 de esos créditos corresponden al trabajo final de máster. En el caso del Máster Universitario en Ingeniería Informática de la UOC, el programa tiene 78 ECTS (3 semestres a tiempo completo o 5 a tiempo parcial), con un trabajo final de máster de 12 ECTS.

Respecto a los contenidos, el Máster en Ingeniería Informática pretende formar un perfil profesional híbrido entre gestión y tecnología: un ingeniero informático con amplios conocimientos tecnológicos que también está capacitado liderar equipos y proyectos de forma exitosa. En este sentido, se diferencia de otros Másters orientados exclusivamente a la dirección TIC (que dejan de lado el componente tecnológico) y de otros Másters tecnológicos más especializados (que sólo potencian la componente tecnológica en un ámbito concreto). Es decir, apuesta por formar una figura de “director técnico”, “jefe de proyecto” o “ingeniero senior”, que ejerce responsabilidades de gestión al mismo tiempo que domina las tecnologías implicadas.

En mi opinión, uno de los puntos fuertes del Máster ha sido el momento de su aparición. El paso al EEES ha coincidido con la maduración de una serie de mercados, tecnologías y tendencias que previamente no habían tenido un papel relevante en los títulos de Ingeniería Informática. Estamos hablando, por ejemplo, de los dispositivos móviles, la usabilidad de las interfícies de usuario o el cloud computing. Aunque revoluciones anteriores como el software libre o el desarrollo de aplicaciones web se habían abierto paso lentamente en los planes de estudio, la tecnología ha hecho grandes progresos que no quedaban suficientemente representados en la formación de los futuros Ingenieros en Informática. Así pues, el Máster aparece en el momento apropiado para ofrecer formación en estos ámbitos que pueden ofrecer grandes oportunidades profesionales y de negocio.

Publicado en Docencia, UOC | Etiquetado , , , , | 1 comentario

IT que destruye valor

En unos cuantos posts recientes (1, 2, 3), hemos repasado los que llamábamos usos estratégicos de las TIC para obtener, mejorar o mantener ventajas competitivas para la empresa y crear valor, más allá de proporcionar los servicios tecnológicos ordinarios, gestionar recursos o dar soporte a las operaciones.

Conviene no olvidar que las tecnologías de la información también pueden destruir valor, valor para el accionista, valor para los clientes y valor social. Desde el punto de vista estratégico, lo que son oportunidades para unos, son riesgos para otros. El análisis que hacer Porter de la Internet es un ejemplo devastador (4). Es lo que él mismo llama la naturaleza “dual” de la tecnología, fuente a la vez de ventajas competitivas y riesgos estratégicos.

Sin embargo, como suele ocurrir, son los riesgos operativos, los riesgos de fallar o de no ejecutar correctamente, los que mayor daño pueden producir a la empresa. Como ocurre con otra clase de funciones infraestructurales y comunes a todos los procesos de negocio, nadie percibe su valor hasta que dejan de funcionar. Hasta el punto que muchos profesionales y algunos autores consideran que la principal misión de la dirección de sistemas es asegurar que las cosas simplemente funcionan y hacerlo sin que se note mucho.

Como en los casos anteriores, cuando se trataba de ventajas, intentemos aquí categorizar los riesgos de una y otra clase (4):

  • Riesgos competitivos. Normalmente, son los que provienen de no comprender la estructura de la competencia (las fuerzas competitivas y su evolución dinámica) y por lo tanto, no disponer de una estrategia clara o que ésta sea equivocada. Esto incluye no examinar la evolución de la tecnología y los riesgos de sustitución, así como la evolución tecnológica de los propios competidores. Los ejemplos de Kodak, DEC, la industria discográfica o el sector de la impresión en plano son clamorosos.
  • Riesgos estratégicos internos. Frecuentemente, son riesgos derivados de no comprender las implicaciones tecnológicas de una decisión empresarial de largo alcance, por ejemplo, en el caso de fusiones y adquisiciones bancarias, o en la apertura de nuevos canales de venta (internet, móviles…), sin la infraestructura tecnológica, de procesos y de personas que la acompañen.
  • Riesgos de la estrategia de IT. Los casos más típicos en los últimos años han sido los de la elección de un sistema de información de empresa (ERP y otros) sin comprender las consecuencias sobre la organización, los procesos y las personas, en los departamentos de negocio y en la propia gestión de IT. Otro error frecuente, al que nos hemos referido en diferentes entradas, es la falta de alineamiento entre la estrategia de IT y la estrategia de la empresa, o entre el CIO y sus jefes e iguales. Es también frecuente equivocarse en la selección y priorización de inversiones, en su volumen y en la secuencia de implantación.
  • Riesgos de ejecución. Son los riesgos de fallar, bien sea por dejar de dar un servicio crítico (las crisis y caídas del servicio, o los problemas crónicos de falta de disponibilidad o tiempos de respuesta) o los retrasos o desviaciones significativas de costes y calidad en los proyectos. Todos ellos afectan a la cuenta de resultados y a la credibilidad del departamento de informática. Los fallos de ejecución pueden serlo de cualquier servicio de la empresa, sea de infraestructura (hardware, software de base, comunicaciones) como de las aplicaciones de gestión como del servicio al cliente o usuario final. Según dice Davenport, no se puede hablar de estrategia si las cañerías no funcionan.
  • Riesgos de seguridad, cada vez más frecuentes y críticos para la supervivencia de la empresa. Suelen incluir desde falta de políticas y procesos de prevención, falta de controles, registros y permisos de acceso, insuficiente inversión en seguridad interna y externa y, actualmente, también los riesgos sobre la privacidad del registro, tratamiento y almacenamiento de los datos personales.
  • Responsabilidad social. Actualmente, empiezan a incluirse entre los riesgos de destrucción de valor de las TIC los que tienen que ver con su impacto social, por ejemplo, los de control de los consumos energéticos, reducción de las emisiones de CO2 y partículas o los del reciclaje de la propia infraestructura.

Ufff, ya se ve que no es fácil. Como dice la profesora Linda Applegate (5), “explotar las oportunidades que ofrecen las TI en el siglo XXI, evitando sus peligros, requiere visión, ejecución efectiva y habilidad para responder rápidamente. También requiere imaginación… y un poco de suerte.”

Notas:

1. http://informatica.blogs.uoc.edu/2012/02/29/usos-estrategicos-de-las-tic-la-cadena-de-valor/

2.http://informatica.blogs.uoc.edu/2012/03/06/usos-estrategicos-de-las-tic-la-estructura-de-la-competencia/

3. http://informatica.blogs.uoc.edu/2012/03/12/nuevos-usos-estrategicos-todavia/

4. Esta clasificación es una elaboración propia, a partir de

Lutchen M. (2004): Managing IT as a Business (John Wiley), capítulo 4. Hay edición española en McGraw-Hill, y

Ward J. y Peppard J. (2002): Strategic Planning for Information Systems (John Wiley).

5. Applegate L., Austin R, McFarlan F. (6ª, 2003): Corporate Information Strategy and Management (McGraw Hill-Irwin).

Publicado en Profesión | Etiquetado , , | 1 comentario

Al menos algo va bien en estos tiempos…

El CENATIC (Centro Nacional de Referencia de Aplicación de las TIC basadas en software libre) ha dado a conocer los datos de uso del software libre en la empresa Española a partir de los datos recogidos por el INE.

Los resultados son magníficos. El 91% de las empresas TIC usan software libre en su infraestructura y el 53,4% del conjunto de las PYMEs españolas usan ofimática libre. En este caso, el término ofimática libre se refiere a aplicaciones como OpenOffice o LibreOffice, sin contar los navegadores web. Los navegadores libres, por su parte, son usados por un 63,4% de las empresas. El dato es relevante, aunque todos sabemos que utilizar un navegador como Firefox es muy sencillo porque básicamente funciona igual que su equivalente propietario. Sin embargo, no pasa lo mismo con las suites ofimáticas, por lo que el hecho de que el 53,4% de las PYMEs utilice ofimática libre es muy significativo.

Teniendo en cuenta que el tejido empresarial de nuestro país está compuesto en su mayoría por PYMEs, y teniendo en cuenta la coyuntura económica actual, parece razonable que estos datos sean fiables e incluso vayan a crecer con el tiempo. ¿Es razonable pagar una licencia de Microsoft Office para una empresa de 5 a 10 empleados, cuando se puede utilizar un producto de ofimática libre? La pregunta no tiene una fácil respuesta. Hace 5 años, seguramente pagar esa licencia no sería un problema. Hoy, quizás sí lo sea. Lamentablemente, sin embargo, un número importante de PYMEs seguramente utilizarán Microsoft Office sin pagar su correspondiente licencia, hecho que entre otros males, frena la expansión del Software Libre.

Si ya más de un 50% de las empresas usan de alguna manera software libre para sus actividades ofimáticas, esto significa que se está perdiendo el miedo a su uso. Como decía alguien, una vez se vea que no es un tema de frikis, es posible que su uso se arraigue, y que estas cifras no se vengan abajo cuando el ciclo económico cambie.

Por otro lado ¿sorprende que el 91% de las empresas TIC usen software libre en su infraestructura? De hecho no. Como ya comenté en una entrada anterior, el software libre ha triunfado más entre bambalinas que en el software que usamos en el día a día. Lo significativo de todo esto es que si las propias empresas TIC lo utilizan, con toda probabilidad lo aconsejarán también a sus clientes. Quizás el dato interesante será conocer cuántas empresas fuera del ámbito de las TIC usan en sus infraestructuras software libre. Pero eso ya será tema de reflexión para otro día.

Hace poco apareció en El País un artículo sobre el triunfo silencioso de Linux. Se constata en éste que el éxito del software libre varía según el tipo de aplicación y el sector. La reflexión que nos queda es, como siempre, si el éxito en algún sector como el de los navegadores llegará algún día a extenderse a sectores como el mismísimo Sistema Operativo.

Mario Gómez Molina es tutor y consultor del Máster Universitario de Software Libre de la UOC. Es además Project Manager de la consultora VASS y dispone de más de 14 años de experiencia trabajando en el mundo de las tecnologías de la información en proyectos de alta complejidad para grandes clientes.

Publicado en Profesión, Software libre | Etiquetado , , , | 1 comentario

Bueno, la ejecución son más cosas

A partir de la entrada anterior, algunos colegas del grupo de gestión de proyectos y de otras partes, me recuerdan que, además de la épica del factor humano (elegir la buena gente, ayudarles a hacer, recompensarles adecuadamente, gestionar la participación, los intereses y conflictos…) y de la experiencia y el arte que no se aprenden en los libros, gestionar proyectos incluye conocimientos, metodologías y buenas prácticas que ayudan a que el proyecto sea un éxito. La práctica, la investigación y las encuestas muestran también que la falta de método es una de las causas de fracaso.

Es verdad. Pero si miramos el PMBOK, la referencia universal de la literatura profesional (1), y otras fuentes, lo que encontramos no da mucho de sí. Los procesos del método de gestión de proyectos en la fase de ejecución son cosas como las siguientes: asegurar la calidad, incorporar, desarrollar y dirigir el equipo de proyecto, distribuir la información, gestionar las expectativas, contratar y supervisar los contratos con proveedores… So what?

Yo creo que lo que ocurre en realidad, son dos cosas. La primera es que resulta imposible separar en la práctica los procesos de “ejecución” y los de “seguimiento y control”. La parte más tangible, si se puede decir, de los métodos generalistas de ejecución es la que tiene que ver con tareas administrativas, y no les quito importancia: comparar continuamente los planes con el actual, identificar y gestionar los cambios, preparar informes y, sobre todo, levantar señales de alarma (2).

Lo segundo es que durante la ejecución es precisamente cuando se despliegan las metodologías específicas de cada tipo de proyectos, las que tienen que ver con el conocimiento de determinado tipo de habilidades y productos y, en definitiva, con la competencia técnica. Y en esto, cada proyecto y cada producto son diferentes. Hay que saber y tener un método determinado para construir un software a medida, para implantar un sistema de información de empresa (ERPs, CRMs, BIs…), para desarrollar una aplicación multimedia o para desplegar antenas de wi-fi en una ciudad… De hecho, para muchos profesionales, eso y no otra cosa es la gestión de proyectos. Y representa no menos del 40% del consumo de tiempo y recursos (3).

Todas estas cosas (gestión, control y competencia técnica) son ciertas y valiosas y su feliz combinación hace un proyecto exitoso o, como digo siempre, razonablemente exitoso. En palabras de Andersen y otros: “La competencia profesional no es suficiente para asegurar el éxito si los aspectos gerenciales no funcionan. Y, al contrario, ninguna clase de soporte administrativo puede asegurar el éxito si falta la competencia profesional. Los dos (gestión y capacidad profesional) son cruciales para el éxito” (4).

Notas:

1. VV.AA. (2008, 4ª). A Guide to the Project Management Body of Knowledge (PMBOK Guide) (Project Management Institute).

2. De hecho, hemos propuesto la integración de estas dimensiones en Rodriguez J.R., García Mínguez J y Lamarca Orozco I. (2007). Gestión de proyectos informáticos: métodos, herramientas y casos (Editorial UOC).

3.  Kerzner H. (2006, 9ª). Project Management. A systems approach to Planning, Scheduling and Controlling (John Wiley).

4. Andersen E.S., Grude, K.V., Haug T. (2006, 3ª). Goad Directed Project Management (Kogan Page).

Publicado en Profesión | Etiquetado , , , , | 2 comentarios

Sobre la ejecución

Un día me dijo Rafael Macau, director de los Estudios de Informática, Telecomunicación y Multimedia de la UOC, o sea nuestro “super-decano”, que es además miembro del grupo de conocimiento de Dirección de Sistemas de Información, que encontraba en nuestros materiales sobre gestión de proyectos o dirección de tecnologías poca cosa sobre lo que realmente importa, o sea, la ejecución.

Es verdad, y no sólo nos pasa a nosotros. Los profesores y consultores somos más hábiles en el diseño de modelos y metodologías y en el estudio y enseñanza de los procesos de planificación y control que en aquello donde se juega el éxito de los proyectos, de los departamentos de sistemas y de las empresas, la capacidad de delivery, o sea que las cosas que tienen que pasar pasen realmente.

Una vez un jefe tejano (rollo Dallas) que tuve nos metió a todo el equipo en un autobús y nos llevó a comer a Segovia. Antes, nos paramos delante de los restos del acueducto romano. Nos hizo bajar y nos dijo: “La informática es esto. El agua tiene que entrar por alguna parte, tiene que pasar por arriba y tiene que llegar a los clientes”.

Yo creo que, al final del día, la ejecución y sus virtudes y defectos, dependen sobre todo de la gente y de la gente que escoge, supervisa y ayuda a otra gente. Por eso es difícil de explicar y de estudiar. Michael Krigsman, posiblemente el bloguero más leído del mundo sobre gestión de proyectos (1) decía hace unos días: “Los fallos de IT ocurren cuando los directivos ejercen un juicio pobre, poseen poca experiencia, reclutan a la gente inadecuada, ignoran los signos de alarma y, sobre todo, se equivocan a la hora de involucrar a los empleados de una manera que los ponga en el camino del éxito”. Los fallos de ejecución, gestionando proyecto o cualquier otra cosa, tienen que ver, sobre todo, con la experiencia y habilidades directivas: la gestión de las expectativas, la gestión de los conflictos de intereses dentro de la organización y entre los clientes, fabricantes e integradores, la falta de participación y colaboración. No es fundamentalmente un problema de metodologías, de planificación o de control, aunque éstos ayuden.

Decía Peter Drucker, el inventor del management moderno: “El planificador cree que las ideas mueven montañas. Pero son los buldócers los que mueven las montañas. Las ideas solamente les dicen a los buldócer a dónde tienen que ir. El planificador tiene que encontrar gente para que ejecute los planes y tiene que saberlos explicar. El planificador se tiene que adaptar a medida que el plan se pone en acción y, finalmente, tiene que decidir cuándo tiene que dejar de empujar el plan.” O sea, dejar hacer, dejar que la buena gente haga, porque saben y quieren hacerlo. Decía Vicente del Bosque, en su época en el Real Madrid: “La primera misión del entrenador es no molestar a los jugadores”.

Uno de los mejores libros de gestión de empresas de los últimos años se llama Execution (2) y está escrito por Larry Bossidy, que trabajó muchos años en General Electric cerca de Jack Welch y por Rob Charan, autor y consultor. El libro se puede resumir en siete recomendaciones:

1) Conoce a tu gente y tu negocio.
2) Insiste en el realismo. El realismo es el corazón de la ejecución.
3) Establece objetivos y prioridades claras.
4) Persíguelas y asegura su cumplimiento: quién es responsable de qué y para cuándo.
5) Recompensa a los que ejecutan.
6) Desarrolla las capacidades de tu gente.
7) Conócete a ti mismo.

De todas ellas, la que más me gusta es la quinta. Dicen Bossidy y Charan: “Reward the doers, those who execute. They will save your life”. Los que hacen nos salvan la vida cada día.

Notas:

1. Blog: IT Project Failures
2. Bossidy L. y Charan R. (2002). Execution (Crown Business)

Publicado en Profesión | Etiquetado , , , , | 3 comentarios

Reducir el fracaso en los proyectos de Business Intelligence (II)

Con motivo de la intervención del profesor Jordi Conesa en el Foro Profesional de Inteligencia de Negocio de Barcelona, el próximo miércoles 25, hablábamos hace poco de cómo reducir el fracaso en proyectos BI, aceptado que conseguir el éxito en estas cosas es un objetivo a lo mejor demasiado ambicioso. Seguimos:

5)     No intentar arreglar en el BI lo que no está arreglado en el transaccional. Es una pequeña observación técnica y funcional que resulta útil. El BI debería ser un repositorio ordenado de datos o agregaciones de datos y un conjunto de extracciones y explotaciones de éstos convertidos en información inteligente. No es el sitio para arreglar problemas relacionados con la falta de calidad o claridad de los datos (volveremos sobre esto más abajo) o con desastres producidos en la implantación de los sistemas de base (el ERP, el CRM, etc.). Pero sirve para ponerlos de manifiesto y, a continuación y sin falta, ir allá para arreglarlos. Estas son cosas que tampoco suelen entender muchos clientes y sobre las que hay que hacer apostolado.

6)     Proyectos mestizos, capacidades mestizas. En los proyectos de BI se juntan o se deberían juntar personas con perfiles muy diferentes, pero capaces de trabajar juntos de manera productiva. Al menos se me ocurren los siguientes: gente que puede tener un diálogo de negocio con los directivos, normalmente de alto nivel y sin bajar mucho al detalle; gente que tiene que convertir eso en indicadores, fórmulas y datos; gente que conoce bien lo que pueden hacer y no hacer los productos y los fabricantes; arquitectos y modeladores de datos, que es gente rara; diseñadores y creativos, que además entiendan la ergonomía de la presentación, el uso y la navegación que harán los usuarios; gente que conoce los sistemas transaccionales, las aplicaciones y las bases de datos de origen; gente de infraestructura, capaz de dimensionar y optimizar sistemas muy pesados a veces y obtener buenos rendimientos.

7)     En el principio, fue el dato. No hay un buen sistema de información de negocio si los datos no son de calidad, o al menos de una calidad que los usuarios y directivos estén dispuestos a aceptar que es razonable y entender los márgenes y riesgos de los errores y trabajar con ellos. Calidad del contenido, el tiempo y la forma de los datos. Contenido quiere decir precisión, relevancia, completitud, concisión y consistencia. Tiempo quiere decir puntualidad, actualidad y frecuencia. Forma quiere decir claridad, detalle, orden y presentación. Nada más y nada menos.

8)     Pasión por los datos. Por eso es tan importante tener primero guerrillas y luego ejércitos de gente apasionada por los datos. Unos son guardianes de la calidad. Otros son analistas, esa clase de gente que pasa días delante de las hojas de cálculo. Otros son modeladores y arquitectos. Hay escasez de toda esta clase de talento. Y aún más, en los niveles directivos (1).

9)     Capacitación. Si en alguna clase de sistema es importante que los clientes puedan trabajar con autonomía, una vez se ha marchado el consultor o implantador, son los sistema de inteligencia de negocio. La inteligencia es la empresa, no puede externalizarse ni delegarse. De nuevo eso invita a productos más fáciles e implantaciones más ligeras. Pero en todo caso, obliga a un esfuerzo grande de transferencia o adquisición de capacidades funcionales y técnicas muy distintas en diferentes niveles de la organización.

10)  Un estilo de vida, un estilo de empresa. Porque en realidad, al final del día, de lo que se trata es de que la gente que tiene que hacer algo con esos datos, convertidos en información y conocimiento, efectivamente lo haga. Las empresas que fallan menos en la implantación de sistemas de inteligencia de negocio y que le extraen mayores beneficios son aquellas que toman decisiones basadas en los datos y no en las mejores opiniones o intuiciones de unos o de otros. Un informe reciente llamaba a esto “a data-driven mindset”, una cultura que cuando existe impregna toda la organización. Empresas que desafían el principio universal del HIPPO (“the highest paid person opinion”), o sea el valor de la opinión del que más manda o el que más gana, al que hacíamos referencia en una entrada anterior hace unos meses.

Notas:

1. Hay un par de informes recientes de Gartner y el McKinsey Institute sobre estos temas, a los que nos hemos referido en una entrada anterior.

 

Publicado en General | 1 comentario

Reducir el fracaso en los proyectos de Business Intelligence (I)

El próximo miércoles 25 se celebra en Barcelona un Foro Profesional sobre Inteligencia de Negocio (1), en el que intervendrá el profesor Jordi Conesa, referente de la UOC en estos temas (2). Los últimos días nos hemos cruzado con él y con la profesora Isabel Guitart algún correo y comentarios sobre su intervención, dirigida a discutir los factores de éxito en la implantación de proyectos BI.

Por mi lado, no me atrevo a decir factores de éxito, la verdad. Pocos proyectos puedo imaginar tan caros, complejos, inciertos; pocos con tantos fracasos en calidad, tiempo, coste y, sobre todo, satisfacción de los clientes; pocos en que la promesa sea tan grande (aumentar la información y el conocimiento organizativo para conseguir mejores resultados y obtener ventaja competitiva) y el resultado tan pobre; pocos en que el enorme esfuerzo de la organización y los implantadores sea tan difícil de convertir en beneficios.

Apenas a partir de mi experiencia, la de otros que saben más que yo y alguna literatura, me atrevo a sugerir algunas prácticas que no van mal para hacer las cosas un poco mejor. Como quedará un poco largo, lo haré en un par de entregas (3).

1)     Para qué hace falta el proyecto. No es trivial. Según los objetivos que quiere conseguir la empresa, cada proyecto es distinto o a lo mejor ni siquiera hace falta. No es igual un cuadro de mando de dirección que un sistema de analítica de costes para los financieros que un portal de datos de toda clase para decenas de unidades de negocio y cuadros intermedios que un sistema de inteligencia comercial que un sistema de ayuda automática para tomar decisiones de producto y precio o hacer ofertas a cierta clase de clientes objetivo.

2)     Quién es el cliente. Aún lo es menos y suele ser menos claro. Yo creo que es un buen principio pensar que un sistema BI (cualquier cosa que eso acabe siendo: dashboards, cubos OLAP, datawarehouses departamentales o corporativos) es algo que debería usar alguien para tomar mejores decisiones sobre el negocio y alinear a la organización y los equipos en una cierta dirección. “Se mide lo que se hace, se hace lo que se mide”. Es imprescindible tener cliente, entender lo que necesita, qué información usa hoy y cómo la usa, qué otra le falta, por qué y para qué. Con quién trabajará y cómo, en qué soportes, qué clase de presentación o de formato les resultará cómodo, amistoso y sobre todo útil.

3)     Hacerlo fácil, hacerlo ágil. El cliente, si lo encontramos, muchas veces no sabe contestar la mayoría de las preguntas anteriores, no quiere escucharlas y tiende a delegarlas en algún subordinado que tampoco sabe. Por eso, si en algún ámbito de la informática tiene sentido utilizar metodologías ágiles, que permitan la interacción e iteración frecuente con el cliente, son los proyectos de BI. Presentar pronto mapas funcionales, prototipos, el lay-out gràfico y revisarlos sobre la marcha creo que son buenas ideas. Un proyecto BI no es un paseo militar y los enfoques de algún gran fabricante germánico son el camino a la perdición. Es también buena idea acostumbrar al cliente a trabajar con primeras versiones que pueden ser aún pobres o contener errores y aprender después monitorizando el uso. Un proyecto BI no se acaba (4).

4)     Pero la arquitectura es compleja. Y esta paradoja no es fácil de solucionar. El modelo de datos que facilita la extracción y explotación de la información es lento y complejo de construir, en especial en los grandes proyectos corporativos, que se alimentan de datos transaccionales de su padre y su madre que tienen poco que ver con la información que necesitan los directivos y el tratamiento que le darán. Por eso, lo importante es la primera pregunta, para qué. Entiendo las ventajas de la integración, de la única verdad tratada por todo el mundo de la misma manera, de la perfecta pirámide que relaciona la entrada de un dato en una tienda con el informe que verá el director general y que además permitirá un tratamiento cruzado y multidimensional. Guay. Pero cada vez me inclino más por sistemas y productos más pequeños y sencillos de construir, implantar y cambiar.

Seguimos otro día, si os interesa.

Notas:

1. http://inteligenciadenegocio.com/barcelona.html

2. Os recuerdo también la oferta educativa de la UOC en Business Intelligence, a la que podéis acceder desde este enlace http://www.uoc.edu/posgrado/matricula_abierta/web/informatica_multimedia_telecomunicacion/embusiness_intelligenceem/

3. Para una introducción al Business Intelligence con dos perspectivas diferentes podéis ver: Conesa J. y Curto J. (2010) Introducción al Business Intelligence (Editorial UOC). Otra lectura muy recomendable es el libro de Davenport T. y Harris J. (2007), Competing on Analytics (Harvard Business School Publishing), del cual hay una traducción castellana en editorial Profit.

4. En proyectos BI son especialmente aplicables,en mi opinión, algunos de los comentarios que presentábamos hace poco sobre la “visión extendida” del proyecto y la participación de los usuarios (http://informatica.blogs.uoc.edu/2012/04/16/como-y-cuando-escuchar-a-los-usuarios-2/)

Publicado en General | 1 comentario

La visión por computador: Una disciplina en auge

Las nuevas tecnologías se van incorporando cada vez más en nuestra vida cotidiana. Por ejemplo, el sistema de acceso a mi gimnasio tiene un control biométrico de huellas  dactilares que verifica la identidad de los socios antes de entrar. Otro ejemplo son las cámaras digitales, que actualmente ya son capaces de detectar caras de forma rápida y robusta.  Además muchas cámaras disponen de una opción que permite hacer fotos automáticamente cuando la persona a la que enfocas está sonriendo.

En concreto, estas aplicaciones son hoy en día una realidad gracias a los avances de la Visión por Computador, una de las ramas de la Inteligencia Artificial que ha experimentado un mayor crecimiento en estos últimos años. La Visión por Computador es la disciplina que estudia cómo procesar, analizar e interpretar imágenes de forma automática. Estas técnicas tienen aplicaciones en muchos ámbitos, como la seguridad, la medicina,  la inspección automática, o la navegación automática.

Dentro de la Visión por Computador,  la detección de objetos es uno de los temas más candentes. El problema parece sencillo: dada una imagen queremos sistemas capaces de encontrar en ella un objeto determinado, como una silla, un libro o un ordenador. Para un humano esta tarea parece algo obvio pero creedme que para una máquina no lo es en absoluto. ¿Dónde reside la dificultad?  Para entender el problema hay que pensar en cómo queda codificada una imagen digital. En general, para una máquina las imágenes son enormes cajas tridimensionales llenas de números. Concretamente, cada píxel (o punto) de la imagen queda representado con tres valores, que codifican su color como una combinación de la cantidad de rojo, verde y azul.  Así pues, cuando una máquina busca un objeto dentro de una imagen lo que realmente hace es buscar patrones que se correspondan con el objeto en particular dentro de estas inmensas cajas  de números.

Hay varios aspectos que hacen de la detección automática de objetos en imágenes un auténtico reto. En primer lugar, la variabilidad dentro de una misma clase es una de las mayores dificultades. Por ejemplo, hay sillas de todos los colores, formas, y para todos los gustos, como podemos ver en la Imagen 2. Esta imagen también ilustra otras dificultades como el cambio de perspectiva, la presencia de oclusiones parciales, o los cambios de iluminación, que pueden crear sombras o reflejos, y producir pérdidas importantes de información. Así pues, para poder reconocer automáticamente sillas en cualquier situación, necesitamos que la máquina sea capaz de hacer una representación genérica de lo que es una silla, y esta representación tiene que ser invariante a todos estos cambios.

Aunque se han hecho avances importantes en la detección automática de objetos durante los últimos años, los sistemas artificiales aún están muy lejos del sistema visual humano. Para nosotros es muy fácil detectar objetos en imágenes, ya que tenemos una habilidad increíble para interpretar las imágenes. Con esto quiero decir que nuestro sistema visual utiliza mucha más información que la que proporciona la imagen, como por ejemplo el conocimiento previo que tiene del entorno. Para darse cuenta de esto fijaros, por ejemplo, en qué pasa si editamos las imágenes que hemos visto anteriormente para que se vean borrosas, perdiendo así una importante cantidad de información:

Ahora ya no es tan fácil reconocer el objeto que hay en las fotografías. Pero, ¿qué pasa si ponemos esta información dentro de su contexto? A continuación se muestran las fotografías completas de dónde han sido extraídas estas imágenes:

Para comprender estas fotografías nosotros utilizamos todo el contexto de la escena,  por esto podemos identificar el tipo de espacio dónde han sido tomadas las imágenes, e incluso podemos detectar con facilidad las sillas que fuera de su contexto resultaban más difíciles de reconocer. Sin embargo, para una máquina entender estas escenas de la forma que lo hacemos nosotros sería hoy en día imposible, porque aún no sabemos dotarlas de esta capacidad de interpretar que tenemos los humanos.

A pesar de ello, actualmente hay un gran optimismo entre la comunidad científica en cuanto al futuro de la Visión por Computador, y en mi opinión este optimismo es bastante realista. En la pasada década se ha conseguido desarrollar algoritmos para resolver problemas que hace 20 años parecían irresolubles, y todo hace pensar que la tendencia seguirá al alza. Además, con el creciente protagonismo en nuestras vidas de los dispositivos móviles con cámaras, como tabletas y smartphones, estoy segura de que en los próximos años habrá cada vez más sistemas de visión artificial en nuestro día a día.

Referencias:

- D.A. Forsyth, and J. Ponce. Computer Vision: A Modern Approach. Prentice Hall Professional  Technical Reference. 2nd edition 2011.

- A. Torralba. Contextual priming for object detection. International Journal of Computer Vision, Vol. 53(2), 169-191, 2003.

- P. Felzenszwalb, R. Girshick, D. McAllester, D. Ramanan. Object Detection with Discriminatively Trained Part Based Models.  IEEE Transactions on Pattern Analysis and Machine Intelligence, Vol. 32, No. 9, September 2010.

Àgata Lapedriza es matemática y doctora en informática. Es profesora de los Estudios de Informática, Multimedia y Telecomunicación de la UOC, dónde coordina asignaturas de matemáticas y estadística. También dirige proyectos de grado y máster en el ámbito de la inteligencia artificial. Su actividad de investigación se centra en temas de visión por computador y aprendizaje computacional.

Publicado en General | Etiquetado , | Deja un comentario