31 de octubre de 2013

Cambiar de proveedor de Outsourcing de TI más fácil (y menos costoso) que nunca antes

Hasta muy recientemente la decisión de cambiar de proveedores de Outsourcing tenía casi siempre un alto costo asociado.  Pero las ventajas que han disfrutado los proveedores actuales en los clientes están desapareciendo progresivamente y hacer la transición de un proveedor a otro se ha hecho mucho menos dolorosa.

Anteriormente para cambiar proveedores había que realizar un movimiento completo de todos los procesos contratados en outsourcing.  Se pueden  mencionar varias razones para que este fenómeno esté ocurriendo:
  • La cadena de suministro de servicios se ha continuado fragmentando hasta llegar al nivel de outsourcing de tareas y de soluciones específicas y eso aumenta las posibilidades de un cliente cambiar de proveedor en componentes individuales.
  • Anteriormente el proceso de contratación de outsourcing se hacía a través de RFP complejos y ahora esto ha pasado a ser más un proceso colaborativo de compra y de esa manera se obtienen servicios estandarizados de los proveedores de outsourcing.  Estos son más fáciles de comparar y de trasladar.
  • También impacta el hecho de los avances de la “automatización” que ha venido ocurriendo dentro del trabajo de outsourcing.  Esto puede hacer bajar costos hasta en un 60%, lo cual indudablemente se puede convertir en un argumento muy convincente para un cliente.

Los proveedores de outsourcing más impactados son aquellos cuyo modelo de negocio está basado en mano de obra y especialmente mano de obra barata.  Esto es cierto ya que la cadena de suministro de servicios depende cada vez menos de mano de obra directa. Ha aumentado significativamente la automatización dentro del de outsourcing y al realizarse  la entrega en la forma de “servicio-como-software” – lo cual equivale a la virtualización del ambiente físico de outsourcing.  En áreas como redes y data center la automatización ya hoy en día puede llevar a disminuir los requerimientos de staff en 50%.

Otro tipo de proveedor que se puede ver impactado en este cambio en el mundo de Outsourcing son los que tienen un muy gran tamaño (tipo IBM, Fujitsu, Hewlett-Packard u otros), ya que no necesariamente todos tengan la agilidad y flexibilidad para hacer las adaptaciones necesarias a tiempo para ajustarse a los cambios en el mercado. 

La percepción en el mercado es que estos cambios vienen muy rápidamente y ya en 2014 se estarán sintiendo. 

El artículo completo está CIO.
http://bit.ly/15MoEbk 
 

Cómo hacer outsourcing del desarrollo de aplicaciones (CIO)

Si se necesita una aplicación a la medida y no se dispone de los recursos internos, existen opciones externas de contratación.  Sin embargo, este proceso puede ser complejo y no es fácil  o automático lograr éxito en este tipo de contratación.  En este trabajo se identifican  elementos que pueden fallar en el proceso de outsourcing de desarrollo y se hacen recomendaciones  que pueden ayudar a obtener el mejor resultado en este esfuerzo.

El proceso de outsourcing es particularmente complejo para proyectos creativos como los de aplicaciones, donde percepciones subjetivas sobre como las cosas son y como deberían ser deja mucho espacio para malos entendidos y es importante cubrir esas brechas.
 
Para el mejor aprovechamiento del material:
  • Con el objetivo de establecer una base de referencia común inicialmente se hace una resumen del proceso de desarrollo.
  • El material es útil para Gerentes Usuarios en empresas corporativas y para Alta Gerencia en empresas medianas y pequeñas.
  • Se hablará de empresa desarrolladora o de contratista aún cuando es factible que haya situaciones en las cuales se trate de la contratación de un solo desarrollador.  Las circunstancias e ideas aplican independientemente de la magnitud de la empresa desarrolladora.

Cómo hacer un Desarrollo 

En el mundo ideal la empresa desarrolladora debe poseer conocimiento técnico sólido y ser un asesor de confianza, además de tener conocimiento del mundo de la ingeniería de software y estar en sintonía con las necesidades de negocio y las demandas específicas del proyecto a contratar.  Debería con seguridad y confianza guiar al cliente a través del proceso de definición de alcance, mantener una clara comunicación a través del proceso de desarrollo, mientras que continuamente se va cumpliendo cada compromiso oportunamente en el tiempo a medida que la aplicación va tomando forma.

A groso modo el proceso de la creación de la aplicación a la medida debería lucir así:

1.     Descubrimiento
El cliente debe comunicar sus objetivos y expectativas y la empresa desarrolladora debe construir un entendimiento de lo que se espera lograr, identificar lo importante y separar lo opcional y también tener claro lo que el cliente espera ver al final del proyecto.

2.     Alineamiento del alcance
En el alcance debe estar identificadas las funcionalidades, listas y diagramas, así como algunas pantallas.  Las partes tienen acordar lo que se construirá.

3.     Desarrollo-Codificación
Con descubrimiento y alcance definidos ya se debe comenzar la codificación.  Dependiendo de la complejidad esta puede tomar semanas o meses, y puede involucrar uno o varios desarrolladores trabajando en equipo.

4.     Revisión
A través del proceso de desarrollo se debe mantener un proceso acordado de revisión en el tiempo.

5.     Entrega/Producción
Es la puesta en uso de la aplicación y hay que considerar que posteriormente que toda aplicación requiere mantenimiento y mejoras futuras.

Seleccionando la Empresa de Desarrollo apropiada

Existen múltiples opciones para la ejecución del trabajo:  Desarrolladores independientes, empresas especializadas y servicio de “app-builder” en línea.  Si el cliente le da importancia al tema de comunicaciones es preferible una empresa ubicada físicamente cerca del cliente. Si se decide trabajar con empresas desarrolladoras a distancia, además de considerar los mecanismos de comunicación a aplicar, también podría ocurrir que hay que aceptar diferencias de horario. 

Es importante consultar con conocidos y colegas y tratar de tener varias opciones para la selección.  Una vez que estos estén identificados, necesariamente deben ser evaluados. Son importantes las visitas a sus páginas web, así como los ejemplos de trabajos recientes. Finalmente, hay que analizar  las recomendaciones que traen de trabajos anteriores y es imprescindible hablar con los clientes-referencia.

Hay tres preguntas esenciales que es conveniente hacer a cada empresa candidata:

a)     Saben comunicarse?
Debe haber buena comunicación entre las partes. Un buen contratista debe preocuparse por explicar el todo y también cada punto, no debe molestarse con las preguntas “estúpidas” y aclarar la terminología al cliente.  Si existen dudas, hay que pensarlo muy bien antes de contratar.

b)    Conocen su materia?
No hay garantías en la vida, pero si el contratista ha hecho un proyecto similar eso da cierta seguridad.  Hay que solicitar ejemplos y no dudar de entrar en detalles.  Generalmente aplicaciones que tienen buena presentación visual indican que hay buen trabajo realizado por los desarrolladores. Hay que chequear referencias y allí es importante averiguar sobre la capacidad de respuesta a la corrección de fallas de la empresa desarrolladora.  

c)     Entregan a tiempo?
Sin limitaciones de tiempo y recursos cualquiera puede construir una aplicación.  Pero como esa no es la situación del cliente, hay que cerciorarse que el contratista tiene una record comprobado de cumplimiento a tiempo de objetivos y proyectos. Aquí también la consulta con los clientes-referencia es valiosa.

Definiendo el alcance de la Aplicación

Descubrimiento es la etapa en la que se debe lograr definir todos los detalles sobre lo que la aplicación debe ser y debe hacer. Durante la etapa de Descubrimiento se crean las bases para que el proyecto pueda  avanzar  y completarse exitosamente, esto se logra al ir aclarando expectativas y conceptos erróneos y concretando ítems que se puedan accionar.  

Es importante tener en mente que para que todo esto funcione  se requiere un buen contratista y también un buen cliente!  Se puede ser buen cliente si desde el principio se provee:
 
  • Una clara descripción de lo que será la aplicación.  
  • Una lista corta de las funcionalidades o características que la aplicación debe tener.  Aquí se requieren solamente las más básicas.
  • Una lista con prioridades de  las características que sería adicionalmente conveniente tener.
  • Ejemplos de aplicaciones similares que después de analizadas gusten al cliente
Hay que mantener siempre el sentido de las prioridades.  Desarrollo de software es típicamente definido por compromisos, por ello la disponibilidad de ciertas funcionalidades probablemente limitara la creación de otras.

Es determinante comunicar claramente los tiempos del proyecto, la fecha esperada de arranque y todas las fechas intermedias acordadas para la ejecución del proyecto.  También se debe definir el soporte futuro, así como la respuesta a fallas de la aplicación.  Todo esto se debe hacer preferiblemente por escrito.

Después de la etapa de Descubrimiento el contratista entregará documentos que capturan el “alcance” total del proyecto.  Hay que revisar en detalle línea por línea y diagrama por diagrama antes de firmar la aceptación.  Estos documentos son los mapas del proyecto y todo lo que esté fuera de ellos será probablemente facturado por separado el contratista.

Cumpliendo con fechas comprometidas

Completadas las etapas anteriores el contratista se dedicará a codificar.  Para proyectos pequeños probablemente se desaparecerá por dos semanas y aparecerá con alguna codificación de la aplicación  que ya funciona.  En los proyectos más complejos habrá una serie de puntos de revisión contra objetivos para los componentes específicos del proyecto.

La preocupación principal debe ser revisar con cuidado los componentes codificados, para asegurar que se cumple con expectativas y alcances.  Hay que analizar las características detalladas de la aplicación.  Si algo no gusta o no funciona hay que manifestarlo.

La entrega!!

En el Siglo XXI no existe software terminado.  Las aplicaciones requieren actualizaciones para adelantarse a las amenazas de seguridad y además ya que los usuarios siempre requieren nuevas "funcionalidades".  Una vez que se realiza la entrega exitosa es conveniente celebrar con el contratista, pero también planificar los próximos pasos.
El artículo original aparece en CIO.
http://bit.ly/17wD2Sh

16 de octubre de 2013

Marcapasos miniaturizado e inalámbrico será lanzado en Europa



Marcapasos miniaturizado e inalámbrico que se puede insertar en el cuerpo sin cirugía invasiva ha recibido aprobación para su uso en la Unión Europea.  El dispositivo se inserta en forma intravenosa directamente al corazón.  Su tamaño equivale a la décima parte de los marcapasos actuales  y tiene una batería integrada. 


Los marcapasos tradicionales se introducen a través de cirugía y dentro de un bolsillo se colocan el marcapaso y su cableado asociado.  Precisamente es ese cableado el que tiene mayores posibilidades de fallar.  También el bolsillo tiene asociado el riesgo de infección.


Este nuevo marcapasos Namostim se introduce con un catéter a través de la vena femoral. Tiene una batería integrada más pequeña que una AAA y con una duración estimada entre 9 y 13 años.  El procedimiento toma una media hora y el dispositivo está diseñado para ser fácilmente recuperable para cambio de batería. 


Algunos expertos consideran que este es “el futuro de los marcapasos”.  Otros son más cautelosos, indicando que se debe adquirir conocimiento y experiencia con este nuevo tipo de marcapasos.   También existen pruebas con otros fabricantes que están probando modelos inalámbricos, con más de cien pacientes desde el año 2012. 


Es interesante recordar que el primer marcapasos fue implantado en 1958 y hoy en día hay unas 4 millones de personas en el mundo con algún dispositivo de control de ritmo cárdiaco y se estima que hay unos 700.000 nuevos usuarios en forma anual.


http://bbc.in/17ttQhs

Hay vida más allá del móvil


Algunos advierten que la adicción al móvil ha ido demasiado lejos. Buscan que amigos y familiares, guarden los teléfonos y se concentren en las personas que tienen delante y no en el correo electrónico, Facebook, Twitter e Instagram. 

Estas son algunas de las curiosas estrategias que algunos estan aplicando:

·         Dejar el teléfono en un recipiente al llegar a casa hasta después de terminar la cena.
·         Crear zonas de prohibición de dispositivos.
·         Prohibir los aparatos digitales en el dormitorio.
·        La aparición de competiciones como el “juego de los teléfonos amontonados” que está ganando popularidad en algunos restaurantes.  La primera llamada atendida paga la cena!!! 

Ese sentimiento quedaba reflejado en un vídeo de YouTube que ha sido visto por 24 millones de personas. En él aparece una joven, interpretada por la actriz Charlene deGuzman, a la que nadie hace caso porque las personas que la rodean están obsesionadas con sus teléfonos. En el bowling, logra un strike y cuando se da la vuelta para chocar los cinco con sus amigos, estos no le quitan sus ojos a sus pantallas. 

Como curiosidad este problema ha sido abordado incluso por los planificadores de bodas. Hay parejas que no quieren que los invitados lleven teléfonos ni cuelguen fotos suyas en la Red. Esto puede tener diversos motivos: garantizar la intimidad, evitar afectar a quienes no han sido invitados, otros  quieren asegurarse que solo se publican fotos favorecedoras.... Estas celebraciones tienen un nombre: “bodas desenchufadas”. (El País-España & New York Times)

Los CIO malvenden TI a los líderes empresariales

Investigaciones recientes realizadas por Forrester y el TMB Council a través de  800 entrevistas traen algunas sorpresas.  Estas son algunas de opiniones de los CEO:

·         Los líderes empresariales no entienden lo que sus departamentos de TI hacen y los CIO no se venden bien.
·         La mayoría de los CEO no conocen el presupuesto de TI ni como se mide el éxito de esta unidad.
·         Los CEO piensan que el presupuestos de TI es 60% mayor que la realidad y que más bien frenan el negocio.
·         Los CIO opinan que TI consume el 5% de presupuesto de la corporación, mientras que los CEO piensan que IT es el 8% del presupuesto.
·         De las 10 métricas (KPI) que el CEO utiliza para medir CIO, hay 4 métricas que no son usadas por el CIO.
·         Aceptan que sigue habiendo una “brecha” en el lenguaje que ambas partes usan.

El reporte indica que:

·         Los CIO deberían aprovechar ahora que TI es más crítico para el éxito del negocio.
·         Los CIO deberían convertirse en socios del negocio, haciendo que TI sea la tecnología del negocio.
·         2/3 del presupuesto de TI se dedica mantenimiento en las grandes corporaciones y  eso limita la capacidad de acción de TI en comparación con las posibilidades que se presentan en las nuevas corporaciones.
·         Las métricas y los bonos que se usan en TI tienden a enfatizar seguridad, lo cual limita la capacidad de aprovechar nuevas oportunidades.

Se recomiendan aplicar métricas asociadas a  cuatro métodos para medir y comunicar la contribución de los CIO al negocio:

1.     Salud … midiendo la efectividad de los controles existentes.
2.     Entrega … identificando y midiendo la capacidad de TI en la entrega de sus promesas a los “stakeholders” internos y externos.
3.     Resultados …  donde se identifican y miden las contribuciones de TI a los resultados del negocio.
4.     Agilidad … donde se trata de predecir la habilidad del TI existente.

El artículo está en Computerweekly.

 

Los CIO deberían alentar y fomentar Nubes independientes- por cuenta de usuarios


En menos de tres años Gartner predice que 35% del gasto de TI vendrá fuera del presupuesto de TI.  Los empleados regularmente se suscribirán a colaboración, analíticos y otros servicios en la nube simplemente apretando un botón.  Otros construirán sus propias aplicaciones con herramientas basadas en la Nube.   Hoy en día estos servicios representan menos del 1% del gasto, pero tres años está a la vuelta de la esquina!!!

La mayoría de los CIO odian la idea de ver a sus usuarios comenzar a utilizar servicios en la Nube sin la intervención de TI, sin embargo existen razones para permitirles que experimenten.  Molesta al CIO que existan implementaciones de  Dropbox, Google y Amazon Web Services hechas sin control de TI, y TI debería aprovechar los aspectos positivos de estas experiencias:

·         La habilidad de lograr que los usuarios se emocionen con el uso de recursos basados en la nube.  Hoy en día la mayoría no conocen la nube, que hace y que beneficios puede traer.
·         La habilidad de descubrir los verdaderos requerimientos del negocio.  Quienes están tratando de aprovechar la nube se debe a que TI no ha podido responder a sus requerimientos y podría ser una buena guía futura para TI.
·         La habilidad de recopilar data sobre el uso de la nube.  Este será un elemento adicional para ir definiendo la estrategia empresarial en la nube.

Seguridad, el desconocimiento detallado de las actividades realizadas así como el riesgo que estas experimentaciones pueden tener sobre la continuidad del negocio son algunos de los elementos negativos.  Sin embargo, las posibles recompensas exceden por mucho los riesgos. 

El artículo fue publicado en Infoworld.

MIT presenta M-Robots tipo "Terminator"

El Laboratorio de Ciencias de la Computación y de Inteligencia Artificial de MIT ha presentado como resultado de su investigación robots en forma de cubos que se pueden dar vuelta, saltar y ensamblarse entre ellos en diferentes formas.  Se les conoce como M-Blocks y no tienen componentes externos, ya que operan bajo un mecanismo interno de rueda voladora (flywheel) y se unen entre ellos usando magnetos.

Los científicos piensan que ejércitos de estos M-Blocks se podrían usar para realizar reparaciones temporales a puentes o edificios.  También se podría aprovechar su capacidad de auto-ensamblaje o de operación como andamiaje reconfigurable.  Estos robots modulares tienen la gran ventaja de adaptarse a cualquier tarea o terreno que se les presente.

Pensando a futuro, los científicos esperan tener cientos de estos robots en un piso, capaces de identificarse entre ellos mismos, pudiendo fusionarse y transformándose bajo demanda en una silla, una mesa o un escritorio.  A soñar!!!

Hoy en día los M-Block se controlan a través de instrucciones computarizadas enviadas por radio wi-fi, pero en un futuro se espera que se les cargue directamente con algoritmos computarizados y eso los hará totalmente autónomos y con capacidad para adaptarse a ambientes diferentes. Robots con sensores y cámaras podrían participar con trabajos específicos en situaciones de combate o de emergencia.
http://bbc.in/1emJLTY


Data Center: Propio o en Outsourcing?

En el pasado, lo común era que las organizaciones fueran propietarias de y operaran sus propios data centers.  Sin embargo, temas como virtualización, diversas opciones de acceso a la nube así como las modalidades en las cuales las empresas manejan TI están teniendo impacto en las decisiones con respecto a los Data Center. 

Entre las consideraciones de costo para montar y mantener un data center propio a nivel global se encuentran las siguientes:
  • La conexión eléctrica puede alcanzar US$160.000 por megavatio.
  • La conexión de fibra puede llegar a US$400.000 por kilómetro.
  • El equipamiento requerido para reducir posibilidades de fallas puede estar en el orden de US$27.000 para un centro Tier 2 y aumenta a US$34.000 para un Tier 3 y US$45.000 para un Tier 4.
  • Se estima que el equipamiento del Data Center debe ser actualizado cada tres años.
Hoy en día existen y se aplican con otras dos opciones adicionales para Data Center muy interesantes:

1.     Nube Pública
  • Una opción como AWS (Amazon Web Services) o Rackspace permite alquilar espacio bajo demanda.  Es atractivo para quienes tienen requerimientos que se comportan en forma de picos y valles.  En pocos minutos se dispone de un servidor y esta opción facilita la innovación.
  • Los costos de base pueden ser de US$23 mensuales para un servidor Linux (512MB RAM y 20GB en disco), un servidor grande (Windows, 30.720MB RAM y 1.200GB de disco) puede estar en el orden de US$1.600 mensuales. 
  • De acuerdo a IDC el costo en la Nube Pública puede ser 70% menos que un Data Center propio medido en un período de 5 años.
  • Como ejemplo, News Corporation de Murdoch utiliza Amazon para construir nuevas aplicaciones y su data center para las aplicaciones existentes.  News Corporation tiene hoy 500 servidores AWS y espera tener 13,500 servidores para 2015.
2.     Alquilar espacio en Data Center
  • Esta opción permite reducir costos, ya que puede procesar más eficientemente.
  • Tienen además redundancia en potencia, conexiones y unidades de refrigeración.  
  • Esta opción puede adicionalmente cubrir la necesidad de respaldo.
Interesante artículo en ZDNet
http://zd.net/16c6NaJ