Etiqueta: costes

Cómo elegir

Es muy típico escuchar a alguien que lleva usando una aplicación informática durante algún tiempo que no usa ni el 25% (en el mejor de los casos) de las funcionalidades que trae de serie dicha aplicación. ¿ Por qué pagar entonces el 100% cuando sólo se usará un 25% ?

La respuesta es fácil, para poder reducir los costes de fabricación del producto, en este caso de una aplicación informática, se debe «producir en serie» (en el argot TI desarrollos estándar) de manera que permita llegar con el mismo tiempo de producción (desarrollo) al máximo número de usuarios. De esta manera pagaremos el 100% del precio para usar sólo ese 25%, claro que el 100% del precio de un producto estándar suele ser bastante más económico que el 100% (que sólo cubrirá el 25%) de un producto a medida.

Las virtudes de los productos estándar, sobre todo en la pyme, son más que evidentes. El ahorro en costes lo podemos ver desde dos puntos de vista, económicamente y en tiempo, que al fin y al cabo se convierte en una cuestión económica también. Es importante tener en cuenta el aspecto «coste en tiempo», pues según el caso puede representar un esfuerzo mayor para la empresa, y a menor número de usuarios de la aplicación, mayor coste en tiempo, pues evidentemente si sólo tiene 2 usuarios la aplicación y uno está dedicado en parte a «apuntar», probar y comunicar al proveedor los errores, estaremos pagando a una persona para que «depure» (busque funcionalidades requeridas, compruebe el correcto funcionamiento de las desarrolladas, etc…).

Tan sólo por este aspecto (coste en tiempo) y a no ser que la gestión y necesidad de la empresa sea algo muy específico, en el 99,9% de los casos deberíamos optar por aplicaciones estándar.

Una vez que ya sabemos por qué hemos elegido una aplicación estándar, tendremos que evaluar las que en principio dan cobertura funcional a nuestros requisitos (gestión de nuestra empresa) al menor coste posible (como es obvio). El problema es ¿ cómo decidir cuando una aplicación merece o no la pena el esfuerzo económico ? Aquí tenemos que buscar razones objetivas para poder medir con la misma unidad. Por ejemplo, ¿ cuántas personas necesitaríamos y cuanto tiempo dedicarían a realizar la gestión de manera manual ? Con esto ya tenemos una medida base sobre la que calcular lo que nos vamos a ahorrar. Ahora tan sólo se trata de elegir una metodología de evaluación económica de proyectos para poder comparar las diferentes alternativas. Es importante tener en cuenta que el coste de la aplicación no es el único que tendremos que sopesar, además tendremos que añadir:

  • Coste de mantenimiento anual de la aplicación, cuando aplique (sea posible y se desee incurrir en él, que debería ser siempre)
  • Coste de hardware para alojar la nueva aplicación. Aquí siguiendo la arquitectura típica de las aplicaciones actuales tendremos que hacernos las siguientes preguntas:
    • ¿ es necesario nuevo Hardware para ejecutar la aplicación en el «Servidor» ?
    • ¿ es necesario actualizar/cambiar el hardware de los puestos ? En muchos casos la obsolescencia de los puestos hace que esto sea un coste añadido.
  • Formación de los usuarios

Como se puede ver, tomar la decisión correcta conlleva tener en cuenta muchos factores.

Es obvio que estas son las consideraciones generales, y dependiendo de cada circunstancia, habrá que valorar otras muchas más.

Offshoring

Cada vez estoy más convencido de que esto de la gestión, va por «tendencias». Algún iluminado suelta el rumor que tal o cual cosa es «lo mejor de lo mejor», y acto seguido los «Líderes» hacen caso cual corderitos al gurú del management que está de moda.

Offshoring (según Wikipedia):

outsourcing internacional es la relocalizacón de procesos de negocios de un país a otro, usualmente en busca de costos más bajos o mano de obra. Incluye procesos como producción, manufactura, servicios, e incluso innovación o investigación y desarrollo (I+D).

En los comienzos lo suyo era enviar todo lo que a nosotros nos cuesta hacer, a países como India, donde la mano de obra y los costes son mucho más reducidos que los nuestros, y por lo tanto reducimos costes «directos» del proyecto. Pero claro, nos dimos cuenta que no tenemos un nivel de Inglés lo suficientemente bueno como para «no tener problemas» y lo que se reducía por un lado, lo gastábamos en «costes de control», Overrun, etc … Vimos la luz. Lo suyo es que se haga en un país de lengua hispana y con unos costes al menos muy similares a los de países como India. Bueno en TI no son tan buenos como los primeros, pero … A ver que vemos por el mapa….. Venga a este que además es de los menos conflictivos de la zona, a pesar de tener sus problemas (corralito, etc….). Y allí es donde van muchas de las grandes, o al menos donde recomiendan ir a sus proveedores, para reducir costes.

El tema es: es efectivo este tipo de procesos para cualquier tipo de proyecto (relacionado con TI) ?  Mi respuesta es que depende del tipo de proyecto y de las expectativas de reducción de costes.

No es lo mismo encargar un desarrollo que gestionar un entorno. Ya lo decía un famoso cantante, No es lo mismo. Si bien en el primer caso está claro (o debería estarlo por la documentación a entregar antes del arranque) lo que se ha de esperar, en el segundo no lo esta tanto. Si, que si SLA, KPI, y demás siglas, pero al final se va solucionando lo que va ocurriendo en el día a día, que por cierto no coincide en sus horas de oficina.

Si ya es complejo solucionar problemas en la distancia (también es verdad que no todos requieren de proximidad) se le añade el hecho de que para cubrir con las expectativas de reducción de costes, se tiene, al menos, la tentación de contratar a personal muy poco cualificado, y sin experiencia («juniors»), a los que por lo que cobran les va a dar igual ser ingeniero de sistemas, que dependiente de hamburguesería. El grado de rotación es muy alto, y la calidad del servicio muy baja. Pero claro al gurú de moda, que en la mayoría de los casos llega, hace «la consultoría» y se va, los problemas posteriores no le importan, o si … pero eso ya es otra factura diferente.