En su mayoría los proyectos del Clúster son proyectos pilotos, es decir tienen como objetivo determinar la factibilidad técnica, operacional y económica de una iniciativa innovadora. Esta característica se refleja también en el monto de inversión, que se sitúa entre 400.000 y 800.000 dólares. Al ser pilotos no tienen recursos asignados para una difusión/expansión masiva; ésta se debe dar en el tiempo a través de la comercialización del servicio o producto.
En la transición del piloto a expansión se pasa también de contar con un plan de sostenibilidad a un verdadero plan de negocio, el cual ya tiene que estar definido a grandes rasgos desde el diseño del proyecto a fin de poder validar las hipótesis iniciales y precisar las necesidades del emprendimiento. En el plan de negocio se tendrá que detallar la operación, el mercado objetivo, la estrategia de mercadeo, el equipo de gestión, precios de los servicios y otras fuentes de ingreso, evolución futura del servicio, e impacto de la competencia. También se tendrá que considerar la institucionalidad del servicio (¿será la misma agencia la que continuará con el proyecto o se prevé la creación de una entidad separada?), los aspectos legales a considerar y las alianzas que pueden ayudar en su crecimiento. Todo esto tiene que traducirse en proyecciones financieras realistas y en un cronograma razonable. También, las lecciones aprendidas del piloto tienen que ser debidamente incorporadas al plan.
En algunos casos la etapa de expansión puede que no sea necesaria: i) el proyecto ha producido cambios en el sector que permanecen después de su finalización, con lo cual cumplió con su misión, ii) el proyecto no ha tenido éxito y/o la agencia ejecutora se desinteresa del servicio; o iii) la agencia ejecutora, especialmente si es una entidad de gobierno, tiene recursos propios para masificarlo. Pero, en general, en todos los proyectos que han desarrollado con éxito un piloto y en los cuales existe una clara voluntad institucional para asegurar su expansión, se debe prever una etapa de difusión y masificación. Sin embargo, en los casos en los cuales hay una demanda e interés por parte de las agencias ejecutoras en la expansión, los proyectos enfrentan retos para su sobrevivencia como son la falta de los recursos financieros necesarios (que frecuentemente no están a disposición de las agencias ejecutoras por ser son organizaciones sin ánimo de lucro), el “desarme” de los equipos de proyecto, la educción de la profesionalidad y memoria del servicio y, lo que es más grave, la pérdida de confianza de las empresas usuarias al percibir que no hay continuidad en la operación. Todo esto puede causar un daño irreparable al proyecto y en la predisposición de los beneficiarios, que una subsecuente financiación no necesariamente podrá resolver.
En el caso del Clúster de TIC el demandar expansión y sostenibilidad a los proyectos se tornó hasta cierto punto en una inconsistencia. Por un lado, el monto de inversión promedio de los proyectos es de 600 mil dólares. Por otro lado, durante la fase de diseño de los proyectos y particularmente, en el caso del ICT4BUS, se consideró que los pilotos exitosos fácilmente podrían tener acceso a recursos para su expansión a través de la agencia ejecutora, de una tercera institución privada o pública o proveniente de la propia comercialización de los servicios o solución desarrollada. Esta perspectiva demostró ser demasiado optimista dada la dificultad de las ONG a acceder a potenciales inversionistas interesados y de alcanzar una masa crítica de empresas que permitieran el autofinanciamiento. Esto llevó al FOMIN a introducir en el Programa una nueva facilidad para financiar la expansión de los proyectos exitosos. Sin embargo, a pesar de que esta facilidad fue aprobada en el año 2008 y de que se han hecho continuos esfuerzos de promoción entres los ejecutores, no fue sino hasta finales del 2009 que se presentó la primera propuesta para aplicar al uso de esta facilidad. A la fecha adicionalmente se han recibido tres propuestas de interés que no se han concretado en propuestas formales.
Si bien es cierto que la facilidad del ICT4BUS para el financiamiento de la expansión de sus proyectos exitosos está vigente, los recursos disponibles son limitados. Esto, aunado al cambio de estrategia del FOMIN centrado en alcance de impacto sistémico, ha llevado a que la duración del proceso de aprobación de los proyectos de expansión se haya incrementado a tal nivel que se pudiera estar poniendo a riesgo la oferta de servicios..
La experiencia indica que la etapa de expansión de un proyecto debe iniciarse antes de que finalice su etapa piloto, garantizándose la financiación de la transición piloto-expansión para asegurar la continuidad en las mejores condiciones. Una alternativa para esto puede ser que, desde un principio, los proyectos tengan previsto en su diseño el financiamiento de una etapa de expansión con un monto máximo. La evaluación final deberá entonces indicar el éxito del proyecto, determinar la utilidad/oportunidad de pasar a la etapa siguiente y ajustar un plan de negocio a ser financiado con los recursos ya reservados para la expansión. También, para la etapa de expansión se puede considerar reducir el porcentaje de contribución del donante.
Entonces, en la ausencia de una estructura de financiamiento suficientemente rápida, dinámica y flexible, se recomienda que los proyectos incorporen ambas etapas en una única financiación a fin de cubrir por lo menos una parte de los costos de lanzamiento y masificación. El financiamiento de la segunda etapa debe ser validado por la evaluación.
Es importante que tanto el ejecutor del piloto como su financiador consideren los escenarios de financiamiento de la operación una vez finalizada la etapa piloto. El financiador debe poder intervenir rápidamente para sostener un proyecto que presenta una buena perspectiva de sostenibilidad técnica, operativa y financiera. Esperar mucho tiempo antes de tomar decisiones de este tipo puede crear un daño grave al negocio y a sus beneficiarios.
|
Este punto intenta abrir la discusión sobre el rol que pueden tener los donantes de los proyectos, como son el FOMIN, ICA/IDRC u otras instituciones privadas y públicas, nacionales o internacionales. No hay lugar a dudas de que, por la tipología de proyectos que se han financiado en el Clúster de TIC, la intervención de donantes está plenamente justificada. En general los proyectos han respondido a una falla de mercado, promocionando iniciativas altamente innovadoras que no tenían acceso al financiamiento privado. En este sentido los proyectos se parecen más a programas de innovación y de investigación y desarrollo, que tienen un rol indiscutible en los sistemas de innovación nacionales y regionales. El valor agregado de instituciones donantes como el ICA/IDRC y el FOMIN está dado por su alcance regional, con lo cual la proyección de las iniciativas es directamente internacional.
El FOMIN ha adoptado una estrategia sectorial de aprendizaje que se basa en la formación de grupos de proyectos similares, los clústers, para compartir lecciones aprendidas y mejorar la visibilidad de los mismos en la región de América Latina y del Caribe. Esta estrategia ha permitido la conformación de una red de ejecutores, directores de proyectos y consultores externos que han tenido reuniones presenciales anuales entre el año 2005 y 2009, representando momentos de aprendizajes importantes para los participantes que, seguramente, tendrán efectos positivos en iniciativas futuras. Con el tiempo la comunidad ha evolucionado y se han agregado otros instrumentos, como la plataforma y foro de la comunidad, un blog, una feria anual de tecnología y los webinars. En una encuesta realizada recientemente, las agencias ejecutoras han manifestado un alto nivel de satisfacción por el rol del Clúster y sus actividades. La gráfica muestra una fuerte predilección por las reuniones presenciales, que se han convertido a lo largo de los años en verdaderos cursos acelerados y compartidos y momentos de socialización entre ejecutores de proyectos (83% las consideran útiles o muy útiles), el contacto y los webinars (61% de los respondientes en ambos casos), seguidos por el foro y la EXPO de tecnología (57 y 47% de los entrevistados respectivamente).
Tanto ICA/IDRC como el FOMIN comparten una metodología de seguimiento de los proyectos financiados que se caracteriza por su participación activa en todas las etapas del proyecto, desde su diseño hasta su ejecución y proyección de continuidad. En general esta presencia y acompañamiento es de gran utilidad ya que sus funcionarios tienen una larga experiencia en el apoyo a proyectos y se identifican con ellos. Sin embargo, cuando la participación de un funcionario responsable del monitoreo de un proyecto es meramente administrativa, limitándose a averiguar el cumplimiento de reglas administrativas y de los indicadores de resultado, sin preocuparse de la viabilidad futura del proyecto ni de apoyar al ejecutor en la solución de los problemas no administrativos que puedan surgir, esta participación no contribuye a crear condiciones para la continuidad del proyecto. Desafortunadamente, mucho depende en estos casos de la actitud de los funcionarios designados.
La relación entre la agencia ejecutora del proyecto y el donante se asemeja en una cierta medida a la del inversionista y la empresa start-up. Es una forma de asociación estrecha en la cual no hay solamente flujo de capitales, sino también de aportes intangibles, que van desde el asesoramiento en el diseño del proyecto al desarrollo del plan de sostenibilidad y a la creación de enlaces con otros asociados potenciales nacionales e internacionales. Un donante no debe limitarse a verificar burocráticamente que se cumplan los números y metas del proyecto para poder marcar las casillas en su reporte.
|
La tecnología juega obviamente un rol central en los proyectos que incluyen el desarrollo de soluciones y servicios TIC. Sin embargo la tecnología no es suficiente por sí misma. Esta tiene que ser articulada en el contexto real de intervención para poder generar un cambio de organización, de procesos y productos y de los enlaces con el entorno empresarial, para lo cual la tecnología permite realizarlos más fácilmente y con costos accesibles. La innovación en los proyectos examinados está más orientada al uso de la tecnología para modificar un contexto existente que en la tecnología en sí misma. Obviamente se desarrollaron nuevas soluciones y servicios, pero en la mayoría de los casos no se trata de innovaciones disruptivas, sino más bien incrementales. El elemento disruptivo de la innovación en los proyectos sucede principalmente a nivel de las empresas o de cadenas de valor: es decir que la tecnología, novedosa o menos facilita un cambio importante en el sector, como puede ser la eliminación de intermediarios en la cadena comercial, la disminución significativa del impacto medioambiental de la producción, o el agrupamiento de empresas para compartir una central de compras.
¿La tecnología tiene que ser simple o compleja? En base a la experiencia adquirida es indiferente, ya que en algunas situaciones conviene utilizar una aplicación de escritorio común y poco costosa (o gratuita), mientras que en otros se necesitan sistemas altamente complejos basados en modelos matemáticos y estadísticos que solamente pueden ser desarrollados e implementados por técnicos altamente especializados. Sin embargo, la interface de usuario siempre tiene que ser simple y amigable; mientras más fácil es aprender el uso de una plataforma o de un software, más rápidamente sucederá la adopción y fidelización de clientes, con menores costos de servicios pre y pos-venta.
La base tecnológica de la solución tiene que ser evolutiva, tal como el servicio que se basa en ella. El ejecutor de un proyecto o la organización que está implementando su comercialización no puede ignorar los cambios de tecnología y del mercado y quedarse con la solución sin aportar actualizaciones que la mantengan alineada con las expectativas de los clientes.
Con el tiempo los proyectos del Clúster han ido integrando novedades tecnológicas, siendo las últimas, - obviamente -, aquellas que evolucionaron en el mundo de Web 2.0, la computación en la nube (cloud computing) y las aplicaciones móviles. El mundo de la web 2.0, que se basa en las externalidades de las redes, es un área relativamente nueva en aplicaciones para PyMES, en las cuales los modelos de negocio todavía son incipientes. Estos elementos de web 2.0 se están utilizando actualmente en los proyectos del Clúster en funcionalidades que van desde recomendaciones, comentarios y clasificaciones en tiendas electrónicas (eC@INCO), a comunidades virtuales (ORGANICSNET, CITE VIRTUAL), y uso de redes sociales como facebook y twitter (ORGANICSNET, CATIE).
En el caso del proyecto ORGANICSNET de la SNA la estrategia de difusión utiliza las redes sociales tanto para promocionar el sitio y el conjunto de empresas asociadas, como para acompañar el uso de dichas redes por parte de empresas individuales que quisieran utilizar facebook, twitter, flickr, y/o blogs para su relación con el público. El número de “seguidores” y/o “amigos” de la plataforma de ORGANICSNET y de sus empresas asociadas ha registrado incrementos constantes desde su implantación en 2009, con un flujo creciente de visitas también a los sitios de las mismas empresas.
El proyecto de CATIE sobre agronegocios agrícolas y forestales tiene su propia página en facebook (1200 “amigos” y cuenta en twitter (500 “seguidores”) con noticias acerca del proyecto o de temas y eventos relacionados con el sector.
La tecnología es un elemento que estimula o facilita el cambio en la organización de las empresas y de sus cadenas de valor. Es la demanda que rige finalmente el proceso innovador y un proyecto de tecnología va a necesitar confrontarse con este factor para tener un impacto real. El proyecto va a tener que actualizar continuamente la tecnología, probar nuevos soportes, validar diferentes canales de promoción y/o venta.
|
Un aspecto importante que ha surgido con el financiamiento de proyectos de desarrollo de servicios y soluciones TIC ha sido la propiedad intelectual del software desarrollado. Por reglas aplicables del Banco Interamericano de Desarrollo, normas que derivan principalmente de su actividad de generación de reportes y estudios relacionados con su misión de desarrollo, toda producción intelectual financiada con el aporte de fondos del Banco (o del FOMIN) es de su propiedad. Esta norma se refleja también en los convenios de cooperación técnica que la entidad firma con las agencias ejecutoras de los proyectos y debe también incluirse en cláusulas específicas en los contratos de adquisición de servicios de desarrollo de software. En resumen, todo código de programación y documentación desarrollado en el marco del proyecto pertenece exclusivamente al BID/FOMIN. Productos pre-existentes no son, obviamente, propiedad del Banco.
La discusión sobre la propiedad intelectual y la posibilidad de adaptar las reglas del BID a prácticas más usuales en proyectos de innovación, que consisten esencialmente en dejar la propiedad intelectual al ejecutor de proyectos, ha sido compleja y ha requerido varios estudios. Finalmente el FOMIN optó, con el acuerdo del departamento legal del Banco, por el establecimiento de un modelo que lleva al Banco a adoptar una licencia de código abierto para el software y su documentación (no necesariamente gratuita) accesible a terceros quienes pueden utilizarlas modificarla. La deliberación que llegó a esta conclusión se basó principalmente en las siguientes consideraciones:
- Los modelos de negocio adoptados por los proyectos del Clúster TIC no están basados prioritariamente en la venta de licencias de software, sino en la venta de servicios asociados a las plataformas. En tal sentido es relativamente poco importante para el ejecutor que alguna otra organización se apropie del software, ya que el reto más grande es la ejecución del modelo de negocio, con su personal experto, sus enlaces y alianzas, sus clientes, etc. Las reglas de licencia introducidas específicamente en el marco del programa ICT4BUS permiten también otorgar a la agencia ejecutora el derecho de mantener una licencia exclusiva de uso y comercialización por un tiempo limitado, lo cual puede ser útil para que cuente con un tiempo prudencial para armar e implementar su plan de negocios.
- El uso de licencias de código abierto para los productos de software desarrollados en los proyectos también mitiga el riesgo de perder la posibilidad de que otras organizaciones utilicen el software desarrollado en caso de abandono de la iniciativa por parte de una agencia ejecutora.
A fines de implementar estas reglas, el FOMIN desarrolló, en colaboración con el departamento legal del Banco, un procedimiento para licenciar el software en código abierto con el objetivo de asegurar a los ejecutores un cuadro legal determinado y estable.
Obviamente no todos los ejecutores comparten esta solución y en algunos casos el Banco ha consentido excepciones a las reglas, pero se estima que en muchos casos la resistencia es más un factor cultural debido al modelo de desarrollo de software empaquetado y privativo que ha sido el paradigma de la primera era de desarrollo del software.
La propiedad intelectual de la plataforma de servicios no es un elemento diferenciador de la oferta generada por el proyecto. La organización, conocimiento del mercado, acceso a clientes y modelo de negocio, son los principales factores de éxito del proyecto. El hecho que la propiedad intelectual se quede con el financiador que luego le aplica una licencia de código abierto, como en el caso de los proyectos del Clúster TIC del FOMIN, no impide en nada el desarrollo exitoso de un proyecto de servicios a las empresas.
|
Un modelo de negocio se puede definir como “el mecanismo por el cual un negocio trata de generar ingresos y beneficios. Es un resumen de cómo una compañía planifica servir a sus clientes. Implica tanto el concepto de estrategia como el de implementación” [1]. Según los autores de Business Model Generation, un “modelo de negocio describe el concepto de cómo una organización crea, entrega y capta valor[2]”.
Definir correctamente el modelo de negocio que surge del proyecto piloto es un componente esencial de la estrategia de sostenibilidad del servicio o solución. Varios son los elementos que concurren para definir un modelo:
- Segmento de clientes: es esencial definir el (o los) segmento de mercado en el cual la organización irá a operar y sobre la cual basará su propuesta de valor en función de las necesidades de los clientes. ¿Quiénes son los clientes? ¿Hay que especializarse en un nicho de mercado o el producto/servicio es de demanda masiva? ¿Se trabajará sobre segmentos diferenciados, por ejemplo para un ERP adaptado a dos tipologías de empresas?
- Propuesta de valor: ¿Cuál es el valor que se ofrecerá al cliente? ¿Cuáles son los problemas que se contribuirá a solucionar? ¿Qué conjunto de servicios se estará ofreciendo a nuestro(s) segmento(s) de mercado? ¿Cuáles son las necesidades de los clientes que se está satisfaciendo? ¿Es un producto o servicio innovador? ¿Se diferencia por su precio? ¿Tiene un impacto positivo en los costos del cliente? ¿Mejora su habilidad de acceder a nuevos mercados? ¿Qué grado de usabilidad tiene el sistema, es fácil de utilizar o requiere una fuerte inversión en la formación del personal?
- Canales para la entrega del valor: ¿Cómo vender y entregar el servicio/producto a los clientes y cómo comunicarles la propuesta de valor? ¿Los canales son puntos de contacto con la empresa para vender, entregar, comunicar, evaluar y asistir el cliente en la adquisición y uso del producto/servicio?
- Relación con la clientela: ¿Qué clase de soporte/relación espera el cliente? ¿Cómo se integran en el modelo de servicio/negocio? ¿Cuál es el costo de este tipo de relación? ¿Qué estrategia se implementará para sumar nuevos clientes? ¿Cómo se fidelizará a los clientes? ¿En qué medida, por ejemplo, se pueden utilizar elementos de web 2.0 para favorecer la relación con los clientes? ¿Los clientes van a necesitar una asistencia personalizada? ¿Se pueden utilizar elementos de self-service en la venta o entrega del producto?
- Flujo de ingresos: ¿Cuánto están dispuestos a pagar los clientes por el valor que se le entrega y cómo? Hay diferentes modalidades de rédito que pueden ser combinadas: comisiones por transacción (ejemplo, carrito de compras) o costos recurrentes (subscripción a una plataforma). La formación de precio puede ser fija (depende de variables estáticas, como la cantidad, la tipología de clientes, etc.) o dinámica (depende de condiciones de mercado, como el remate, gestión de rendimiento, o negociado). El objeto de la venta también puede variar: una licencia de software, el arrendamiento de una plataforma, la comisión por el uso de un servicio, el modelo de subscripción, la publicidad o la venta de servicios de valor agregado.
- Recursos esenciales: ¿Cuáles son los recursos (personal, equipamiento, tecnología, marca, financieros, etc.) necesarios para desarrollar, mantener, actualizar, mejorar el producto/servicio?
- Actividades críticas: ¿Cuáles son las actividades necesarias para realizar la propuesta de valor? Ellas pueden incluir el desarrollo y la actualización de un software o de una plataforma, la asistencia técnica a clientes, etc.
- Alianzas cruciales: ¿Cuáles son los socios con quienes aliarse para realizar la propuesta de valor, comercializar los productos/servicios, externalizar algunas actividades o contribuir al financiamiento del emprendimiento?
- Estructura de costos: El modelo de negocio puede basarse en la minimización de costos (automatización pronunciada, externalización de actividades no-estratégicas, estructura de personal reducida, etc.) o estar impulsado por el valor (personalización del servicio, calidad de insumos, diseño del software, etc.). En ambas configuraciones la estructura de costo incluye costos fijos y variables y economías de escala y de función.
Los puntos mencionados, son los ingredientes centrales a tener en cuenta en la definición del modelo de negocio, los cuales se pueden aplicar tanto a una empresa (u organización) como a un servicio específico. Lo más común es que se desarrolle el modelo de negocio de una empresa start-up que se lanza a ofrecer un servicio innovador. Esto se aplicaría entonces, por ejemplo, a la mayoría de los proyectos pilotos del Clúster TIC.
El modelo de negocio puede evolucionar junto con las condiciones de mercado, tecnología, etc. y hasta por la evolución misma del enfoque de la organización. Por ejemplo, en el caso de la Fundación Trazar, que se inició con el propósito de gestionar el servicio de trazabilidad de la carne y eventualmente adaptarlo a otros segmentos de la industria, a causa de las difíciles condiciones del mercado han impuesto un cambio de estrategia posicionándose como una entidad de desarrollo de servicios tecnológicos en el sector agrícola.
Encontrar el modelo de negocio vencedor es, en cierta medida, el “Santo Grial” de todos los proyectos innovadores. No se trata solamente de desarrollar una plataforma novedosa y técnicamente superior o de alinear fuertes alianzas, sino también de definir una propuesta de valor que responda a una necesidad real de las empresas, para la cual ellas estén dispuestas a pagar un precio (si el modelo lo prevé) y entender cómo comunicar ese valor y cómo entregarlo.
Los elementos arriba enumerados pueden confluir en un sistema de gestión estratégico basado, por ejemplo, en el cuadro de mando integral (Balanced Scorecard, o BSC) que ayuda a monitorear el avance del emprendimiento desde la perspectiva financiera, de clientes y mercado, de recursos internos/externos, y de crecimiento e innovación.
El modelo de negocio es la estructura fundamental del proyecto piloto: el piloto debe demostrar su factibilidad económica y técnica e identificar fallas y aportar correcciones en la ruta. Si el modelo de negocio funciona hay una esperanza de sostenibilidad, de otra manera el servicio no tiene la posibilidad de sobrevivir después de la finalización del proyecto. Para alcanzar un modelo de negocio exitoso hay que definir claramente cuáles son las necesidades a las que el servicio va responder: ¿en qué le va ayudar al cliente para solucionar sus problemas? La propuesta de valor es el eje central del proyecto/negocio.
|
Los proyectos examinados son ejecutados por entidades que pertenecen al sector privado y al sector de la investigación científica y académica, los cuales - en la mayoría de los casos - establecen relación directa con empresas privadas proveedoras de servicios de TIC. Son muy pocos los casos donde esta relación se sustenta en el establecimiento de una alianza entre el ejecutor y el proveedor.
En general la experiencia de los proyectos en cuanto al relacionamiento con empresas de software no ha sido de las más sencillas. No son pocos los casos en los cuales ocurrieron retrasos importantes por falta de cumplimiento de la empresa (aliada y/o proveedora). En algunos casos fue necesario cambiar el proveedor (por ejemplo SNA), con el consiguiente retraso de la ejecución y otras consecuencias que complicaron la operación. Los factores que generalmente conducen a la ruptura de la buena relación son: costos de desarrollo, mantenimiento y actualización superiores a lo previsto, no entrega de los productos acordados, no cumplimiento de requisitos y cláusulas contractuales, interfaces de usuarios poco amigables, no cumplimiento del cronograma acordado, falta de personal disponible o alta rotación del mismo, defectos no aparentes, insuficiente calidad del código, testeo inexistente, poca flexibilidad para realizar modificaciones durante el desarrollo, etc. En resumen, las razones que pueden dificultar la relación son numerosas y cada una de ellas puede afectar gravemente el proyecto.
La dificultad encontrada en la relación con los proveedores de software refleja parcialmente el nivel de desarrollo del sector de software en América Latina: las empresas generalmente son recientes, pequeñas y muy frecuentemente no disponen de procesos de calidad y de desarrollo adaptados. Cuando no son simplemente vendedores de soluciones de terceros, su capacidad de responder a necesidades complejas de desarrollo es todavía bastante limitada. Estas debilidades no pueden sorprender si se considera que el sector ha conocido un crecimiento intensivo y desordenado. Creemos que con la adopción de estándares y modelos de desarrollo de calidad se ha iniciado una evolución prometedora que finalmente tendrá su impacto positivo en los clientes de las empresas de software.
Otro punto para destacar es la propiedad del código y la calidad del trabajo. Las empresas tienden a querer mantener la propiedad del código fuente para poderlo re-utilizar con otros clientes o mantener al cliente en una relación de dependencia. Son muy pocas las empresas de software (especialmente pequeñas) que eligen otra estrategia de negocio. Resulta entonces una buena práctica asegurarse que la propiedad del código fuente del software se quede en la entidad contratante. En el caso de proyectos del Clúster hasta es obligatorio que la propiedad se quede en el BID, como ya se mencionó.
Algunas medidas de mitigación de los problemas que suelen ocurrir en la relación con el proveedor de software pueden ser incluidas en el contrato de prestación de servicios. Tal es el caso de la propiedad de los productos y la obligación de entrega del código al cliente. También se puede establecer un calendario de pago contra entrega de productos intermedios que asegure al cliente la posibilidad, si fuera necesario, de cambiar de proveedor sin perder demasiados recursos económicos en el proceso. Otras medidas pueden ser internas o de organización del trabajo; por ejemplo es importante tener un recurso humano interno o externo a disposición que conozca bien de desarrollo de software y pueda relacionarse técnicamente con el proveedor. También se pueden internalizar algunas funciones, (como en el caso de ACDI y UDG), que van desde la definición de las funcionalidades de la solución a desarrollar hasta la programación de algunos componentes del software cuando las soluciones son complejas. Sin embargo, a menos que se disponga de personal especializado (como el caso de UDG), esta medida implica costos de personal fijo que no todos los proyectos pueden justificar. También se necesita que la visión del proyecto sea clara para ambas partes y que la comunicación entre ellas sea fluida y amigable (pero no condescendiente), con una actitud mutua de problem-solving. El cliente tiene que ejercer una supervisión apropiada del trabajo de la empresa y evaluar la calidad de lo que se ha entregado. También es útil prever cláusulas para la modificación y renegociación razonables del contrato. Por otro lado también es importante que la relación cliente-proveedor funcione y que las responsabilidades de la empresa proveedora sean bien incluidas en el contrato. En resumen, se puede concluir que en el caso de la relación cliente - proveedor el proceso de contratación y adquisición es un elemento esencial, aunque no suficiente de por sí para el éxito del contrato para ambas partes.
Por otro lado, es siempre recomendable realizar un llamado público para seleccionar el proveedor, ya que es mejor contar con más opciones de mercado. También es importante, en el proceso de selección, evaluar la calidad del proveedor: las ofertas de bajo costo o muy optimistas no siempre son las mejores. En la fase de supervisión hay que fortalecer los procesos administrativos, garantizando que los requisitos indicados y compromisos asumidos sean debidamente registrados, las decisiones importantes documentadas y justificadas y que los progresos y cambios cualitativos sean medidos. El proceso de selección inevitablemente extiende los tiempos del proyecto (que no debe ser demasiado breve), pero al mismo tiempo da mayores garantías cuanto a la calidad del desarrollo de la firma proveedora.
Una modalidad a considerar en la relación con la empresa de software es de apoyarse en metodologías establecidas, como las incluidas en el CMMI u otros modelos de desarrollo de software. Un elemento central de la metodología consiste en la definición de un cuadro de requerimientos de desarrollo a partir de las exigencias del cliente (o del proyecto). Las necesidades del cliente se traducen inicialmente en requerimientos de producto y de componentes de producto, luego en una arquitectura de producto y de componentes, y en el desarrollo de la solución técnica. La gestión de requerimientos y de sus cambios es la base de una relación operativa funcional entre el proveedor y el cliente y debe ser acordada en su estructura básica desde el principio.
Según lo mencionado hasta acá, no parece que sea una panacea establecer previamente una alianza entre la agencia ejecutora de un proyecto y una empresa de software o que sea esta última quien conduzca el proyecto, como alternativa para reducir los riesgos. Por lo menos, a la luz de lo que se ha observado en estos años, no se considera que esta sea una solución fácilmente viable en mercados que aún no están lo suficientemente maduros y en los cuales el sector privado no percibe perspectivas de rentabilidad que actualmente justifiquen su inversión. Para la mayoría de las empresas de software que operan en el mercado latinoamericano, el sector de clientes de PyMES sigue siendo problemático y siendo las empresas de software normalmente pequeñas y con altos requisitos de competitividad y flexibilidad, un interés eventual en este mercado puede precipitadamente extinguirse si, como es frecuente en este mercado, no hay un rápido retorno sobre la inversión.
Por último, si bien la mayoría de los proyectos financiados por el Clúster han optado por un desarrollo de software a medida para responder a las necesidades complejas del proyecto y sus involucrados, no hay que descartar el uso de software existente donde las aplicaciones disponibles pueden cubrir la totalidad de los requisitos de software del proyecto o, al menos, una parte.
El desarrollo del software, componente esencial de un proyecto de TIC: si se empieza mal, el desarrollo de la solución se transforma en un tormento para el cliente y el proveedor. Por eso es útil limitar cuanto sea posible las áreas de incertidumbre para ambas partes mediante una atenta administración de los requerimientos del proyecto. Al no tener una competencia suficiente al interior de la organización, cosa que sería de todas maneras aconsejable para un proyecto de TIC, hay que considerar la posibilidad de contratar un consultor experto en contrataciones de software para que ayude en el proceso de llamado, selección, contratación de la empresa de software y de validación de requerimientos.
|
Las motivaciones y formas de colaboración son múltiples, y es importante entender bien cuál puede ser el valor agregado para cada uno de los socios institucionales del proyecto. Un proveedor de tecnología va a querer invertir en acciones que potencialmente le puedan llevar un número interesante de clientes futuros; un proveedor de una cadena de valor estará interesado en mejorar su imagen en el sector de pertenencia, su eficiencia en la logística y su relación con los clientes; un gobierno puede estar interesado en apoyar el sector específico o puede tener ventajas directas que derivan del servicio; una asociación gremial empresarial estará interesada en contribuir al desarrollo de sus socios; una universidad o centro de investigación en desarrollar la capacidad tecnológica de su región o en proveer servicios de extensión tecnológica.
Las tipologías y objetos de alianzas abarcan fundamentalmente cuatro áreas:
- Apoyo financiero: es un elemento importante desde la fase de diseño de la operación. Muchas agencias no tienen acceso a recursos suficientes para asegurar la contrapartida del proyecto del FOMIN (o de otros donantes) por lo cual necesitan contar con el financiamiento de otras entidades, que suelen ser gobiernos (locales o nacionales), asociaciones gremiales empresariales, empresas privadas u otras entidades financieras interesadas en la operación. El apoyo financiero puede también ocurrir en etapas finales del proyecto, por ejemplo para el financiamiento de su expansión, o como modalidad de apoyo a las empresas beneficiarias .por ejemplo en la compra de equipamiento de computación o para otras inversiones que sean necesarias. Otra modalidad de financiamiento es la que sucede durante la creación de una empresa spin-off a través de aportes de inversores financieros u operativos.
- Apoyo institucional: la presencia de instituciones públicas o privadas (gobiernos, asociaciones gremiales empresariales, entidades de fomento de la empresa, etc.) es aconsejable para aumentar la visibilidad de la iniciativa y para planear posiblemente el futuro de la operación, ya que pueden favorecer el acceso a recursos financieros, la organización de eventos de difusión o el establecimiento de políticas sectoriales que pueden impactar sobre los beneficiarios del proyecto.
- Apoyo técnico: el soporte técnico a la operación puede provenir de empresas del sector de TIC (telecomunicaciones, software, hardware) que quieren explorar nuevas oportunidades de desarrollo de su negocio o invertir en acciones en el marco de sus actividades de responsabilidad social. También puede provenir de universidades o centros de investigación que tienen una misión de desarrollo de la tecnología e innovación en su ámbito de acción y desde entidades del sector privado que operan en la cadena de valor del sector de intervención o que prestan servicios a empresas del sector.
- Apoyo comercial: alianzas para la distribución de servicios, con entidades o personas involucradas en la cadena de valor directa o indirectamente, sin ser necesariamente una panacea pueden seguramente facilitar el contacto con las empresas clientes. Pueden ser, por ejemplo, empresas de software que estarían interesadas en ofrecer un producto nuevo a sus clientes, o una red de agentes de microfinanzas que pueden ver en un producto de software de contabilidad un valor agregado para sus clientes y por otro lado mitigar los riesgos crediticios de la misma institución. La naturaleza de las alianzas y su impacto en el modelo de negocio varía según la tipología del servicio: en caso de servicios empaquetados la venta es relativamente ágil y el servicio pos-venta está asegurado por el proveedor mismo. En caso de productos altamente personalizados a nivel de la empresa o de servicios que abarcan una cadena de valor la intervención de un socio de distribución puede ser más intensiva ya que usualmente requiere un importante esfuerzo de consultoría técnica.
La gran mayoría de los proyectos del Clúster TIC han establecido alianzas con otras instituciones. De la encuesta de los proyectos del Clúster resultó que de las 38 organizaciones que respondieron, solamente 3 no establecieron ninguna alianza, 13 agencias formaron alianzas con 1 a 3 instituciones, 10 agencias se aliaron con 3 a 5 instituciones y 12 agencias establecieron alianzas con más de 5 aliados. En cuanto a la tipología de las instituciones con las cuales se establecieron alianzas surge el siguiente cuadro:
Es interesante notar el peso de los gobiernos locales (15 menciones), nacionales (13 menciones), gremios empresariales (19 menciones) y proveedores de tecnología (17 menciones). En este último caso, es posible que se incluyan algunas firmas que han sido contratadas por el proyecto; resultando así mismo un dato interesante.
En referencia al objeto de la alianza, el 63% de los acuerdos incluyen apoyos técnicos, el 57% se realizaron para fortalecer la promoción, el 46% para financiamiento y el 34% para mercadeo.
Con el tiempo las agencias ejecutoras de los proyectos del Clúster han reconocido la importancia de las alianzas con entidades interesadas en el objetivo del proyecto. Así lo recapitula FUNDES Venezuela:
La especialización de FUNDES está centrada en la entrega de servicios de formación y consultoría, de allí que para poder entregar esta propuesta de valor, es necesaria la participación de otros actores que coadyuven con el propósito de hacer más competitivas a las PyMES y estén interesados en invertir en ellas; bien sea porque son parte de su cadena de valor (clientes, proveedores, canales) o porque son sujetos de acción de sus políticas de responsabilidad social.[3]
El involucramiento de aliados en el proyecto es generalmente un factor positivo. Organizaciones asociadas pueden aportar recursos económicos o know-how, facilitar el mercadeo, y/o dar más visibilidad y crédito al proyecto. Al establecer alianzas es importante entender cuáles son las motivaciones de los socios potenciales y en qué medida el proyecto puede satisfacer a sus necesidades.
|
[1] Wikipedia: [http://es.wikipedia.org/wiki/Modelo_de_negocio]
[2] Alexander Osterwalder & Yves Pigneur, Business Model Generation, 2009. Traducción del Autor. [http://www.businessmodelgeneration.com/downloads/businessmodelgeneration_preview.pdf]. Esta sección se inspira parcialmente de este libro.
[3] Zoraya Villamediana, Modelo de Vinculación Sectorial, Documento FUNDES Venezuela, diciembre 2005.
Recent Comments