Los especialistas en finanzas no ven con buenos ojos la elección de un proyecto de inversión utilizando el método del plazo de recupero. El motivo es que pondera de igual manera a los flujos de dinero que se dan en tiempos muy diferentes y además no tiene en cuenta el rendimiento total del proyecto.
En el caso de los proyectos online en donde las fluctuaciones son muy importantes el plazo de recupero puede ser útil para al menos dar una idea al emprendedor acerca de cuánto tiempo debe transcurrir para recuperar el dinero invertido.
Un ejemplo de aplicación se puede ver en la siguiente tabla:
Una persona tiene la posibilidad de desarrollar cuatro proyectos de inversión. El proyecto 1 tiene un flujo de fondos desde el año 1 al 4 de 20, 10, 500 y 5000 dólares respectivamente. El coste de oportunidad es del 10% y la inversión inicial de 100 dólares. El resto de la información de cada proyecto se lee de igual manera que la anterior.
Si una persona se guía por el plazo de recupero, calcula el tiempo que se recupera la inversión inicial. En el proyecto 3 es de 1 porque con el ingreso del año 1 se obtiene el dinero invertido. Bajo este supuesto se debería optar entre el proyecto 3 y 4 que cómo se puede ver tienen un valor actual neto menor al proyecto 1. Pero dada la incertidumbre que reina en los negocios online es útil para ayudar a elegir entre proyectos de valor actual neto similar.
Tag Archive for Proyectos
Plazo de recupero ¿es más útil en proyectos online?
El plan de negocio una herramienta indispensable
Muchos emprendedores cuando se embarcan en un proyecto no son conscientes de la importancia que tiene para el nuevo negocio la confección de un plan de negocios. Algunos prescinden de él porque suponen que sólo es necesario para aquellos que precisen financiamiento externo o conseguir algún socio. Pero las estadísticas demuestran que tienen más probabilidad de triunfar aquellos proyectos que poseen un detallado plan de negocios.
Para la confección del mismo se puede o bien contratar a un profesional o tomarse el trabajo de realizarlo uno mismo. Esta última opción demanda más tiempo pero trae como beneficio que dado el análisis profundo que implica realizarlo lleva a que pueda hallarse puntos a mejorar o variables no tenidas en cuenta.
El plan de negocios no solo debe contener los puntos a desarrollar para poner en marcha el emprendimiento sino también una previsión para el mediano y largo plazo. Los plazos más utilizados en proyectos no online son de cinco años y 10 años respectivamente pero dada la volatilidad que posee el mundo de Internet el tiempo se acorta a 3 y 6 años. Aun las finanzas no han adecuado al cien por cien las reglas que rigen los proyectos de inversión convencionales para llevarlos al mundo de los proyectos online.
MANEJO DE RIESGOS ERP
Basado en experiencias con proyectos ERP en los 1990s, se ha encontrado que para que tu proyecto tenga éxito, debes prevenir problemas en las siguientes áreas altamente prioritarias:
* Estrategia de negocios electrónicos,
* Aproximación al manejo del proyecto,
* Tecnología y sistemas complejos, y
* Resistencia del usuario final.
Una pequeña inversión en la comprensión, análisis, rastreo, y prevención de estos principales problemas deberían costearse dado que la mayoría de tales problemas son comunes, esperados, evitables, y detectables tempranamente. Una aproximación viable para reducir la probable falla es identificar los riesgos cruciales en cada punto del ciclo de vida del proyecto, luego construir planes para dirigirlos antes que se conviertan en problemas reales. He encontrado que esta técnica es útil en la evaluación de proyectos ERP y espero completamente que sea útil también para la evaluación de proyectos de sistemas de negocios electrónicos.
La tecnología Midleware y el ERP
La tecnología Midleware ha emergido como el gluten para ser interfaz de estos sistemas y aplicaciones sobre un sistema ERP distribuido. Puedes seleccionar de varios accesos estándar -basado en CORBA, DCOM (Modelo distribuido componente objeto), y otras arquitecturas distribuidas- o desarrollar tu propia. Entérese que los mensajes buggy cliente-servidor o tecnologías objeto compartidas llevaran el sistema entero a un punto de parada.
La mayoría de paquetes ERP no cubren todos los requerimientos de negocios específicos, y por lo tanto puedes necesitar una cierta cantidad de acostumbramiento para completar el ajuste. En algunos proyectos incómodos, el desarrollo de código personalizado se inició sin suficiente meditación y planificación. El subsecuente desarrollo indisciplinado producido por el código de pobre calidad con efectos inesperados, lado no localizado, que se presento de la pobre estructura. El código personalizado también eleva significativamente el costo total de la propiedad del sistema ERP sobre el largo arrastre debido a que las tiendas IT deben actualizar las adaptaciones cada vez que un vendedor actualiza el paquete base ERP.
Una vez que un sistema ERP esta completamente cargado con los datos corporativos necesarios y cientos o miles de personas comienzan a utilizarlo, el desempeño puede sufrir si no haz diseñado por escalabilidad. Los usuarios que deben esperar mas que unos pocos segundos para ver los resultados de su ingreso en la pantalla no estarán felices.
PROBLEMAS TECNICOS ERP
Cuando analizas un proyecto ERP que ha fallado, identificas los problemas que ocurrieron a lo largo del camino, puedes proporcionar indicadores de la falla que viene. Muchos proyectos ERP están plagados por problemas técnicos complejos, que caen dentro de las siguientes categorías generales:
* Paquetes ERP no robustos e incompletos,
* Complejo e indefinidas interfaces ERP a sistema legado,
* Bugs del software Midleware,
* Pobre código Personalizado, y
* Pobre desempeño del sistema.
Los vendedores de paquetes ERP prometen que su producto – generalmente la nueva versión- es robusto y tiene todas las funciones y características para soportar tus procesos de negocios. Si tu cándidamente crees esto, vas al final de la línea. La certificación independiente de tal paquete puede ser la importancia de su peso en oro, y las firmas están instalando establecimientos para hacer esto (por ejemplo, ver Hugh Klipp, “Servicios de Seguro de Calidad para ERP”, 1999)
Para funcionar, un paquete ERP debe ser ubicado en un ambiente IT que contiene ya otros sistemas. La interfaz entre estos dos sistemas son complejos y significativamente afectada por la cercanía de la integración IT total. Necesitaras rigurosos análisis de sistemas legados para entender precisamente los requerimientos de interfaz ERP. Deberías también documentarte de la definición de cada interfaz principal.
