¿Necesito un consultor o un programadorpara poner inteligencia artificial en mi empresa?

La parte difícil no es programar

Programar bien es necesario, y hoy es más rápido y más barato que nunca. Pero la mayoría de las aplicaciones que se dejan de usar no fallan por el código: fallan por el diseño. Piden a las personas que se adapten a ellas —un formato, una navegación, una pantalla más, un dato que hay que teclear dos veces— y la persona, que ya tenía una forma de trabajar, vuelve a su atajo en cuanto puede. Si una aplicación se deja de usar, hay un fallo de diseño: una aplicación tiene que simplificar el trabajo de quien la usa, no crearle uno nuevo.

Con inteligencia artificial esto es aún más cierto, porque la aplicación toca procesos que hasta ahora hacían personas con criterio: recoger un pedido, revisar un expediente, preparar un documento. Integrarla en la empresa —en cómo trabaja de verdad cada persona, con sus excepciones y sus costumbres— es la parte más compleja de todo el proyecto, y es donde se decide si la usan los empleados y los clientes o si se olvida. Por qué pasa eso, y qué cambia con la IA, lo contamos en por qué las aplicaciones tradicionales no consiguen que los clientes las usen.

Un ingeniero recién salido de la universidad puede programar muy bien y no haber visto nunca cómo entra un pedido en una distribuidora, cómo se cierra un mes en una asesoría o qué hace un encargado de obra a las siete de la mañana. No es un defecto suyo; es que ese conocimiento no se aprende programando. Y sin él, el proyecto construye exactamente lo que se le pidió, que casi nunca es lo que la empresa necesitaba.

Qué hace distinto un consultor que conoce el negocio

La diferencia se ve en la primera conversación, en las preguntas. Antes de hablar de tecnología, quien conoce cómo funciona una empresa pregunta por el negocio:

• ¿Qué es lo valioso aquí? Qué genera el dinero, qué lo pierde y qué proceso, si mejora, se nota en la cuenta de resultados. La IA va ahí, no donde es más vistosa.
• ¿Quién hace qué, y por qué así? Cada paso de un proceso tiene una razón, a veces buena y a veces heredada. Distinguirlas evita automatizar un error.
• ¿Dónde se pierde el tiempo de verdad? No donde dice el organigrama: donde alguien teclea dos veces, espera una respuesta o busca un dato en tres pantallas.
• ¿Qué atajo tiene hoy cada persona? Una hoja, una llamada, una foto por WhatsApp. El atajo es información: dice qué le sobra a la herramienta actual y qué tiene que hacer la nueva para ganar.
• ¿Qué hace hoy tu cliente, y qué le costaría cambiar? Si pide por teléfono y audio, la aplicación entra por ahí, no le obliga a aprender un catálogo.
• ¿Qué excepción es en realidad la norma? La tarifa negociada, el pedido fuera de ruta, el expediente que no encaja. Un estándar las ignora; un diseño a medida empieza por ellas.
• ¿Qué puede y qué no puede tu sistema de gestión? Antes de prometer una integración, hay que saber por dónde deja entrar el fabricante.
• ¿Qué exige la norma en este caso? Datos personales, transparencia con el cliente, supervisión humana. Es trabajo de diseño, no una cláusula al final.

Con esas respuestas, la aplicación se diseña para quitar trabajo, no para añadirlo. Y eso es lo que decide que la gente la use: no que sea bonita ni que lleve el modelo más nuevo, sino que le resuelva problemas en lugar de crearlos.

Por qué el negocio dirige el desarrollo, y no al revés

En muchos proyectos ocurre al revés de como debería: la parte técnica decide las funciones que sabe construir y el negocio se adapta a ellas. En Tecnea el análisis del negocio va primero y se documenta —el mapa del proceso, qué es lo valioso, las excepciones que son la norma, el atajo de cada persona y el criterio de adopción— y ese documento es lo que dirige el desarrollo: el equipo técnico construye a partir de lo que necesita la empresa, y cuando hay una duda, gana el negocio. Así lo que se aprende en el análisis llega al código, y no se pierde por el camino.

Tecnea nació en 2016, pero el know-how de su equipo viene de más de veinte años trabajando en sistemas de gestión, procesos y dirección en empresas de distintos sectores y países. Es lo que permite mirar una empresa entera y no solo la parte que se va a programar: saber qué es lo valioso, qué se puede tocar y qué no, y cómo va a reaccionar cada persona cuando cambie su forma de trabajar. No es una capa tecnológica encima del negocio; es un análisis global, documentado, con la tecnología como herramienta y un equipo que la construye a partir de él.

Cómo se diseña la adopción, y cómo se mide

La adopción no se consigue con formación ni con insistencia. Se consigue diseñándola, y esto es lo que hacemos en cada proyecto:

1. 1Entrar por el canal que ya usan. Si tus clientes escriben por WhatsApp y tus empleados sacan fotos de los albaranes, la aplicación acepta eso. Nadie tiene que aprender a hacer lo que ya hace.
2. 2Hablar con el vocabulario de cada uno. «La garrafa de cinco», «lo de siempre», la abreviatura del encargado. El sistema aprende los nombres de las cosas; no obliga a nadie a usar los del catálogo.
3. 3Decidir qué pasa con las excepciones antes de empezar. Cuáles se resuelven en la conversación, cuáles pasan a una persona y cuáles no se automatizan nunca. Es lo que evita que la primera excepción rompa la confianza.
4. 4Quitar, no añadir. Si una pantalla nueva no elimina un paso antiguo, sobra. La medida de éxito es cuántas cosas deja de hacer la persona, no cuántas funciones tiene la aplicación.
5. 5Medir en la prueba de concepto, con casos reales. Qué porcentaje de pedidos, documentos o consultas pasaría sin intervención, y cuánta gente vuelve a usarla a la segunda vez. Con ese número se decide si se sigue; sin él, «adopción» es una palabra.

Dicho en una frase: el objetivo es que empleados y clientes quieran usar la aplicación porque les resuelve problemas y no les crea ninguno. Eso no se promete en una propuesta; se comprueba en la prueba de concepto y se mide después.

Para quién es esto

Para empresas que quieren una aplicación que se use, no un informe que se archive: aquí el análisis termina en una aplicación funcionando con casos reales de tu empresa. Y si lo que necesitas es solo un estudio estratégico, o un producto que ya existe, te lo diremos en la primera conversación.

Lo que hacemos, y es en lo que pedimos que se nos juzgue, es análisis de negocio con la tecnología detrás: documentado, dirigiendo el desarrollo, y con un equipo que construye y mantiene la aplicación a partir de él, en proyectos de entre 5.000 y 20.000 € con una prueba de concepto desde 850 € para verlo antes de comprometer nada.

Cómo comprobarlo antes de contratar a nadie

Cinco preguntas que conviene hacer por escrito a cualquier proveedor, nosotros incluidos, y guardar la respuesta:

1. 1¿Quién va a analizar mi proceso, y qué experiencia tiene en empresas como la mía? Si la respuesta es un perfil técnico sin experiencia de negocio, o un comercial que luego desaparece, el diseño va a salir de un documento.
2. 2¿El análisis del negocio queda documentado y dirige el desarrollo, o es la parte técnica la que decide las funciones y el negocio se adapta? Es la diferencia entre una aplicación que quita trabajo y una que lo añade.
3. 3¿Cómo vais a medir la adopción, y cuándo? Si no hay un número antes de comprometer el proyecto, no hay forma de saber si funciona.
4. 4¿Qué pasa con las excepciones? Quien responde «la IA las resuelve» no ha visto una empresa por dentro.
5. 5¿Qué me vais a pedir a mí? Un proyecto serio necesita horas de la persona que conoce el proceso. Quien no las pide, no va a entender el negocio.

Si prefieres empezar por saber si necesitas un desarrollo o un producto, software a medida o producto de catálogo lo resuelve en cinco minutos. Y si la duda es si tu empresa necesita personal técnico para esto, no hace falta un departamento de informática.