¿Cómo obtenemos un producto/servicio software “innovador”?

Inicio » Actualidad »

¿Cómo obtenemos un producto/servicio software “innovador”?
Autores:

¿Cómo obtenemos un producto/servicio software “innovador”?

Definición práctica sobre estrategias para la innovación en la producción/operaciones software

En la industria del software, existen nuevos enfoques («low code» y «no code»)‎[1]‎[2] y herramientas (por ej. Appinventor ‎[3], Budibase ‎[4], WebRatio ‎[5 ], etc.) que permiten construir software con pocos conocimientos tecnológicos, así como herramientas basadas en IA que generan código de forma automática (GitHub copilot ‎[6] u OpenAI ‎[7] basadas en GPT3). Si en los próximos años la capacidad de construir y explotar productos software aumenta, las empresas más competitivas serán aquellas que tengan mayor capacidad al explorar o descubrir nuevas innovaciones en forma de productos o servicios. Para entonces será necesario entender qué implica «innovar» y cuál es la estrategia más eficiente y eficaz para conseguirlo. Sobre innovación, existe una gran variedad de modelos de referencia y estándares en la literatura (Manual de Oslo y Frascati, Technology Readiness Levels, Art.35 TRLIS, UNEIX 166000:2014, ISO 56002:2019, etc). Sin embargo, como podrá comprobar el lector por alguno de los trabajos de tesis de Manuel Giménez Medina ‎[8], es un proceso complejo que a pesar de que ha sido ampliamente estudiado desde diferentes perspectivas, parece no existir todavía consenso sobre una gran mayoría de conceptos. A continuación veremos brevemente una definición práctica del concepto de innovación (no exenta de consenso), así como algunas de las estrategias existentes y ampliamente conocidas, que permiten promover la innovación en software.

Innovación como ventaja competitiva

De forma práctica, la innovación supone que este proceso sistemático del que venimos hablando, debe tener como resultado algún tipo de ventaja competitiva. La ventaja competitiva debe ser única y sostenible a largo plazo. Una lista de control que podríamos aplicar en nuestros proyectos podría ser la siguiente:

  1. ¿De qué tipo de innovación se trata? Existen muchos tipos de innovación, nuestros proyectos podría tener implicaciones en el modelo de negocio, en el producto (bien o servicio) e incluso en el propio proceso software. Cualquier aspecto que suponga una ventaja con respecto a las empresas de la competencia ¿Cuál es el tipo de innovación de tu proyecto?
  2. ¿Cuál es la ventaja competitiva del tipo de innovación? Time to market, reducción costes, mayor calidad, etc. Nos preguntamos sobre qué aspectos nos ofrecen ventaja ¿Qué ventaja ofrece tu innovación?
  3. ¿Se trata de una «innovación» única? ¿A qué nivel, Objetiva o Subjetiva? Por un lado, la ventaja obtenida podría ser «Objetiva», que implicaría que se ha obtenido algún tipo de novedad o mejora sustancial a nivel internacional (sería única). En la definición del ministerio, esto sería básicamente un proyecto de I+D. Por otra parte, la ventaja obtenida podía ser «Subjetiva» que implicaría que se trata de una novedad o mejora sustancial pero que no es única, podrían disponer de ella otras empresas de la competencia. En la definición del ministerio esto supondría una “Innovación tecnológica (como comentábamos, podría ser confuso este último concepto de innovación). ¿La ventaja obtenida en tu proyecto es única?
  4. ¿Es sostenible a largo plazo? ¿Porque? Nos preguntamos si está Protegida (por ej. patente), es difícil de copiar e imitar (por ej. requiere conocimientos y unos costes excesivamente elevados). La ventaja obtenida en tu proyecto está protegida, ¿es difícil de copiar e imitar por otros?

Descubrimiento/Investigación

Existen estrategias de Descubrimiento/Investigación ampliamente conocidas que podemos aplicar en nuestras actividades generales de I+D para detectar hipotéticas ventajas (que tendrán que ser validadas). A continuación se enumeran algunas de ellas, se incluyen referencias y se comentan sólo algunos aspectos que no se mencionan en la literatura y que pueden ayudarnos a comprender mejor estas estrategias así como su relación con el concepto de innovación.

Design Thinking, Design Sprint

A continuación, realizaremos una breve comparativa entre el proceso Design Thinking y la metodología Design Sprint ‎[13] (inspirada, entre otras estrategias, en Design Thinking). Esta comparación nos permitirá comprender mejor lo que aportan ambas estrategias. Para más información, se recomienda la lectura de las siguientes referencias ‎[9]‎[10].

Design Thinking es un proceso ampliamente conocido, define etapas que (mediante la aplicación de prácticas determinadas) nos permiten comprender el problema (entender el contexto, empatizar con los usuarios, detectar sus problemas y necesidades, entender qué actividades realizan, qué artefactos, cómo se utilizan, etc.) y definirlo (el problema es complejo, no podemos abordar todo y debemos decidir dónde ponemos el foco). Todo lo anterior, como se observa en la figura de “Discovery”, permite aumentar la información sobre el dominio del problema y acotarlo. En la metodología Design Sprint, estas dos etapas (“Empathize” y “Define”) se define en una sola denominada “Understand”. Por otra parte, una vez hemos acotado el problema, lo siguiente es llevar a cabo un proceso de generación de ideas para resolver el problema así como una actividad de toma de decisiones para decidir cuál de estas ideas formarán parte de la solución final. Se trata de nuevo de una actividad que permite aumentar la información y reducirla (en este caso, sobre el dominio de la solución). En “Design Sprint”, el proceso de generación de ideas se lleva a cabo en la etapa “Sketch” y la toma de decisiones en “Decide”. En Design Thinking, ambas actividades se llevan a cabo en una sola denominada “Idea”. Por último, ambas estrategias coinciden en la elaboración del prototipo y la validación del mismo.

Figura 1. Comparativa de Design Thinking vs Design Sprint (font: elaboración propia)

SAPIENS (de Ferràn Adrià)

SAPIENS‎[11] es una estrategia que permite llevar a cabo una mayor y detallada comprensión del problema a partir de la aplicación de un conjunto de métodos relacionados y que permiten analizar el problema desde diferentes perspectivas. Esta estrategia permite que conectemos la información del dominio del problema y que, por tanto, podamos generar nuevos conocimientos que, a su vez, pueden traducirse en nuevas ideas. Los métodos son:

  • método léxico, semántico y conceptual: Cuestionar los términos vinculados a fin de estudio y sus definiciones, elaboración de un léxico propio que permita definir con precisión el objeto de estudio
  • método comparativo: Establecer paralelismos con otros objetos de estudio, en su conjunto o de forma parcial, analizando sus semejanzas y diferencias, ayuda a mejorar el diccionario y la clasificación.
  • método clasificatorio: Cuestionar las clasificaciones de conceptos vinculadas con el objeto de estudio, ampliación del listado de términos y definiciones para crear una clasificación propia.
  • método sistémico: Situar el objeto de estudio en el contexto y analizar el sistema.
  • método histórico: Estudiar el origen y la evolución del objeto de estudio, concretando en una cronología de hitos y épocas.

Como se menciona anteriormente, todos los métodos anteriores están relacionados de alguna forma. Por ello, las ideas parecen emerger como consecuencia de las “conexiones” realizadas como resultado de aplicar los métodos anteriores. Por tanto, no se trataría de una estrategia como Design Thinking o Design Sprint, de hecho, los autores parecen haber combinado SAPIENS con Design Thinking o Design Sprint. Más bien, encajaría en la etapa de “Understand” e “Idea” (aunque en esta etapa no de forma explícita, sino más bien, de forma implícita).

Figura 2. Relación de Design Thinking vs SAPIENS ((fuente: elaboración propia)

Design Science (metodología de investigación para ingeniería)

Por último, la ciencia del diseño [12] es una estrategia orientada a la investigación en ingeniería que persigue el desarrollo y la validación de conocimientos prescriptivos. Siguen un proceso muy apoyado en técnicas y prácticas de investigación que permiten comprender en detalle y validar tanto el dominio del problema como el de la solución (encuestas, casos de estudios y experimentos). Por eso es posible centrarse en sólo algunas etapas del proceso como por ejemplo sólo en el dominio del problema, sólo en el domino de la nueva solución que estamos proponiendo o incluso en comparar soluciones que ya existen (por ej. para compararlas e inferir algún tipo de conocimiento nuevo). Sigue más bien un enfoque Build2Learn, es decir, el aprendizaje se realiza una vez construido, demostrado y evaluado el artefacto. Para más información, se recomienda el seminario de Óscar Díaz publicado en la web de SISTEDES ‎[11].

Figura 3. Design Science (Fuente: ‎[14])

Conclusiones

Por último, finalizaremos con las conclusiones más relevantes:

  • Un concepto de definición práctica de “Innovación” sería el de considerarlo como una ventaja competitiva como resultado de un proceso de I+D: Este concepto implicaría orientar los procesos de software (investigación/descubrimiento, desarrollo, operaciones) a una «Ventaja competitiva» que sea «única», «sostenible», «protegida», «difícil de copiar» e «imitar»
  • Descubrimiento / Investigación (conocimiento):
    • Las estrategias como design thinking o design sprint (y derivadas), nos permiten (1) Comprender y definir el problema, (2) explorar y tomar decisiones sobre la solución (3) construir y validar la solución.
    • El conjunto de métodos de SAPIENS nos permite comprender mejor el problema y que las ideas emerjan como consecuencia de la conexión que se lleva a cabo del conocimiento. Nos permiten: (1) Definir conceptualmente el objeto de estudio, (2) Definir el sistema del objeto de estudio, (3) Definir la evolución histórica del sistema y el objeto de estudio y (4) Clasificar y (5) comparar el objeto de estudio con otros similares.
    • Para la investigación en ingeniería, existen además estrategias como Design Science. Aplica técnicas y prácticas de investigación que permiten comprender en detalle y validar tanto el dominio del problema como el de la solución (encuestas, casos de estudios y experimentos). Es posible centrarse en sólo algunas etapas del proceso.

REFERENCIAS

[1]. El País, “Low Code cómo aparender a programar sin saber programar”, accesible online: https://elpais.com/tecnologia/2022-05-06/low-code-como-aprender-a-programar-sin-saber-programar.html, último acceso: Julio 2022

[2]. ITUSER, ”Estos son los principales beneficios del lowcode en el desarrollo de aplicaciones”, accesible online: https://www.ituser.es/actualidad/2022/05/estos-son-los-principales-beneficios-del-lowcode-en-el-desarrollo-de-aplicaciones, último acceso: Julio 2022

[3]. MIT Appinventor, accesible online: https://appinventor.mit.edu, ultimo acceso: Julio 2022

[4]. BuidBase, accesible online: https://budibase.com, ultimo acceso: Julio 2022

[5]. WebRatio, accessible online: https://www.webratio.com/site/content/es/plataforma-de-desarrollo, ultimo acceso: Julio 2022

[6]. GitHub copilot, accesible online: https://github.com/features/copilot, ultimo acceso: Julio 2022

[7]. OpenAI examples, accesible online: https://beta.openai.com/examples/, útlimo acceso: Julio 2022

[8]. Giménez Medina Manuel, “Towards an agile innovation capability maturity framework to enhance investments on ICT organizations”, CAiSE-DC 2020: 32nd International Conference on Advanced Information Systems Engineering (2020), pp. 21-31. ISBN/ISSN: 1613-0073. https://idus.us.es/handle/11441/107426

[9]. The Design Sprint, How smart teams start big projects, accessible online: https://www.thesprintbook.com/, ultimo acceso: Julio 2022

[10]. IDEA Design Thinking, accessible online: https://designthinking.ideo.com/, ultimo acceso: Julio 2022

[11]. Metodología Sapiens, conectando conocimiento, accesible online: https://metodologiasapiens.com/, último acceso: Julio 2022

[12]. Óscar Díaz García, La Ciencia del Diseño: del desarrollo de software a la investigación en software. Accesible online: https://biblioteca.sistedes.es/seminario/seminarios-sistedes/la-ciencia-del-diseno-del-desarrollo-de-software-a-la-investigacion-en-software/, último acceso: Julio 2022

[13]. Jake Knapp, J. Z. (15 de 12 de 2016). Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. First Simon & Schuster. ISBN 978-1-5011-2174-6. Obtenido de http://www.gv.com/sprint/

[14]. Johannesson, P., & Perjon, E. (2014). An Introduction to Design Science. Springer International Publishing, DOI: 10.1007/978-3-319-10632-8