EMPRESAS DE SOFTWARE

1. EMPRESAS DE SOFTWARE ¿ UNA INVERSIÓN DE ALTO RIESGO ? Joan C. Rivera / Joan Tubau Barcelona, 17 de Junio de 2003

2. ALGUNAS EXPERIENCIAS (MALAS) • SSA • BAAN • META 4 • DPSI • ON-LINE • INTERGLOBAL

5. News BAAN COMPANY 03 Dec 2001 Baan Company in liquidation 31 May 2000 Recommended cash offer by Invensys for Baan 21 Jan 2000 Baan Company announces decisive moves to accelerate growth

6. Características y escenario • Oportunidad tecnológica estratégica para el país. • Soportada por infraestructura humana y material técnicamente capacitadas. • Posibles grandes márgenes, ligados: • Ideas brillantes, no siempre tecnológicas • Conocimiento claro del mercado y como alcanzarlo • Conocimiento preciso de los factores de coste y como controlarlos • Grandes frustraciones, no siempre explicables

7. PRODUCTO MODELO DE NEGOCIO GESTIÓN EL PARADIGMA

8. La perspectiva cambia cuando se habla de futuro. Los factores más determinantes en este caso son ganar clientes y el reclutamiento de personal. Las razones para ello no son difíciles de entender. Con el equipo fundador volcado en el desarrollo de su producto o servicio, los aspectos comerciales ocupan a menudo un segundo plano. Hasta que no hay nada para vender, no hay motivos para preocuparse por la cuestión. La primera fase del desarrollo de la compañía se centra en la tecnología en sí misma, proteger la propiedad intelectual y hacer prototipos que funcionen. Sólo cuando los productos están listos para ser ofrecidos al mercado, surgen los factores complejos de solucionar y para los que los promotores no poseen la sapiencia requerida, como las ventas, la distribución, las licencias, los servicios al usuario o las alianzas con otras compañías. Cinco Días 10/2/2003

9. PRODUCTO • De corta vida (rápida obsolescencia) • Entorno tecnológico inestable e impredecible • Bajas barreras de entrada • Viabilidad sancionada por los usuarios • Auditoría de calidad

10. MODELO DE NEGOCIO • No contrastado (internet) • poco/no desarrollado • Canales • Soporte • Precio (aceptación) • Costes • Entrega • Mercados

11. GESTIÓN • Poca atención a los costes • Financiación • Experiencia empresarial

12. El Paradigma no se sostiene • El ciclo de vida se define: • Windows, SAP, ISARD, FBSS, MAINT, PCONTA • El producto no siempre existe: • Análisis histórico, SSA, DPSI, Interglobal • Los cambios tecnológicos no suceden “de repente” • Unix, Linux, Windows, Java, Corba, …. • Desviaciones en plazo y coste LA PARTE vs EL TODO

14. El Paradigma no se sostiene • El ciclo de vida se define: • Windows, SAP, ISARD, FBSS, MAINT, PCONTA • El producto no siempre existe: • Análisis histórico, SSA, DPSI, Interglobal • Los cambios tecnológicos no suceden “de repente” • Unix, Linux, Windows, Java, Corba, …. • Desviaciones en plazo y coste • LA PARTE vs EL TODO Capacidad de gestionar el proceso de desarrollo

15. El Riesgo para los inversores puede minimizarse/acotarse • Externos • Capital Riesgo • Blue Angels • M&A • Internos • Software Houses • Grandes usuarios: • Inhouse Development • Compra • Aplicaciones Críticas

16. Aspectos de la “crisis del Software” • Persistentes desviaciones en costes, planes y objetivos. • Muchos de los problemas derivan más de la propia naturaleza y capacidad humanas que de la propia complejidad del SW. • Aversión al riesgo • Inaceptable optimismo en planes y previsiones • Uso preferente de la intuición frente a los modelos cuantitativos

17. Confianza en la inversión • Al adquirir un producto ya establecido en el mercado, su evaluación es fácil. • Cuando se trata de invertir en un desarrollo, en una fase inicial o intermedia, el tema requiere el cuidadoso análisis de una serie de aspectos • “In God we trust,...all other bring data”

18. ¿Que se puede hacer? • Mas vale prevenir que curar • Auditoria y revision de los distintos elementos del negocio implicados en el desarrollo/adquisicion • Asegurarse de la fiabilidad de los ciclos tecnicos, comerciales y financieros • Correccion de potenciales deficiencias e inhibidores • Implantacion de procesos y controles que aseguren una valoracion/reaccion continua de los factores de riesgo

19. Algunas preguntas que es necesario formularse Un producto es algo más que unos programas Identificar y analizar sus distintos aspectos y componentes ¿Cómo funciona la organización? ¿Cómo está el producto? Valorar su efectividad, capacidad de desarrollarlo y nivel de riesgo ¿Cuál es el coste real del producto? El propio de su estado actual, más el de reducción de riesgo

20. Requisitos • Demanda • Territorios • Competencia Adecuación al Mercado • Plataformas • Dependencias • Evolución del Mercado Entorno Técnológico • Organización • Procesos • Planificación • Gestión Capacidad de Realización Capacidad de Implantación • Calidad • Instalabilidad • Soporte • Mantenimiento Facetas de un Producto: Areas de valoración Producto

21. Competencia Mercado Usuarios Requisitos Funcionales Entorno Tecnológico Geografías Proceso Requisitos Técnicos y Comerciales Ideas de soporte Capacidad de Desarrollo Canales • Especificaciones • Fases • Plan de Producto • Packaging PRODUCTO Adecuación al mercado

22. Dependencias Otros Productos Sincronismo Plataformas Plataforma A Plataforma B Plataforma C Migrabilidad Plataforma B1 Producto (B) Producto Portabilidad Plataforma D Entorno tecnológico de un producto Producto ...siguiendo/anticipando las tendencias del mercado

23. Calidad Mantenimiento “Off the Shelf” Desarrollo Soporte Directo Terceros Acuerdo Comercial Packaging Soporte Directo Remoto Soporte Directo Local Oficinas remotas o limitación geográfica Complejidad Implantación del producto en el mercado Clientes ...Decidir en limitaciones, costes (y dónde), margen y negociaciones

24. Producción y Calidad de Resultados Planificación Fiable Gestión Consistente Procesos Definidos, Medibles, Optimizables Capacidad de Realización Madurez de la Organización Objetivos • Productos de calidad • Cumplimiento de fechas • Control de costes • Minimización de riesgos • Identificar y valorar procesos críticos • Analizar planes y su fiabilidad • Identificar y analizar conceptos, métricas y dependencias • Analizar organización y eficacia de gestión • Identificar y valorar mejoras para reducir riesgos

25. 1124 organizaciones de desarrollo de tamaños diversos (de <25 a >2000 empleados). • 37,5% en la cota de planificables y gestionables. • 43,2% simplemente capaces de hacer proyectos repetibles. • 19,3% son capaces de hacer algo en base a heroicidad personal. • Las cotas más bajas de madurez se concentran en las organizaciones de hasta 100 empleados. • Entre 100 y 300 empleados, sólo un 7% alcanzan el nivel de “cuantitativamente gestionables”. Algunos datos al respecto • Encuesta 2002 del SEI de la Carnegie Mellon University

26. Madurez organizativa • Expresión de la capacidad de: • Producir resultados técnicos de calidad aceptable • Planificar con fiabilidad • Gestionar proyectos de forma consistente • Mejorar sus procesos de forma iterativa • Es la única garantía de que una idea se va a convertir en algo comerciable. • Existen diversas metodología para medirla, pero todas ellas se basan en la experiencia y el conocimiento.

27. Análisis de riesgo • Se puede efectuar mediante el estudio sistemático de los elementos expuestos. • Se tienen que estudiar las distintas dimensiones del riesgo, técnicas, organizativas y comerciales. • Los problemas básicos son comunes a organizaciones de todas las dimensiones

28. Análisis de riesgo –(continuación) • La problematica es escalable • La importancia del riesgo es proporcional a la valoracion economica del proyecto frente a la capacidad de la entidad inversora • Ni el esfuerzo de revision ni las soluciones a aplicar son las mismas, en esfuerzo, para un proyecto de 10 p/a que para uno de 100s de p/a en avanzado estado de gestacion, pero los conceptos a analizar son los mismos. • No es lo mismo analizar el riesgo que establecer un plan de calidad, pero éste puede ser indispensable para reducir el riesgo.

29. RESUMEN • SÍ SE PUEDE REDUCIR EL RIESGO A NIVELES “NORMALES” • DUE DILLIGENCE TECNOLÓGICA • EL CUMPLIMIENTO DE LA NORMA UNE 166002 REDUCE PERO NO ELIMINA EL ALCANCE DE LA DUE DILLIGENCE • EQUIPO CON EXPERIENCIA EN DESARROLLO • CON CAPACIDAD PARA INTERACCIONAR CON EL EQUIPO DE LA DUE DILLIGENCE TRADICIONAL (SINERGIAS) • LA EVALUACIÓN DE COSTES PARA RESOLVER/ELIMINAR DEFICIENCIAS EN EL PRODUCTO/PROCESO DE DESARROLLO ES CLAVE EN LA VALORACIÓN DE UNA EMPRESA DE SOFTWARE • AMBITO/PROFUNDIDAD VS INVERSIÓN

30. Algunas experiencias propias: • Más de 25 años en desarrollo de productos SW para el mercado mundial. • Producto ISARD: • Soporte de comunicaciones para grandes redes de datos en aplicaciones • transaccionales críticas. • 23 años de presencia en el mercado. • Más de 100 clientes, activo todavía en 45 instalaciones. • Familia de Productos FBSS/LANDP: • Software para aplicaciones de estación de trabajo bancaria. • 20 años de presencia en el mercado mundial. • En los primeros diez años llegó a instalarse en: • Más de 1000 clientes (BofA, Lloyds, “la Caixa”, DB, ...). • Más de 500.000 licencias • Proyecto IBM – Olimpiada Barcelona-92: • Infraestructura técnica de la gran red informática de tres niveles. • Integración de desarrollos de cuatro grupos independientes. • Análisis y gestión de rendimiento. • Implantación, soporte técnico y gestión del sistema.

31. Otras experiencias participadas: • Informática El Corte Inglés: • Laboratorio de desarrollo de productos para Retail. • Diversos productos para el Sector: punto de venta, e-commerce, logística. • Orientación a Segmentos Medio y Alto. • Estudios para PYME • Grup FIHOCA: • Software para aplicaciones de gestión de conocimiento. • “Training Games”. • Herramientas de ayuda en gestión y mantenimiento de Webs. • Deister: • ERP/1 – Aurora. • Implantación pragmática y realista de un ERP para PYMEs con fuerte base Web. • Análisis y evaluación para posible integración en estrategia de Retail. • Excelente ejemplo a tener en cuenta.