Necessito un consultor o un programador per posar intel·ligència artificial a la meva empresa?

La part difícil no és programar

Programar bé és necessari, i avui és més ràpid i més barat que mai. Però la majoria de les aplicacions que es deixen d'utilitzar no fallen pel codi: fallen pel disseny. Demanen a les persones que s'hi adaptin (un format, una navegació, una pantalla més, una dada que s'ha de teclejar dues vegades) i la persona, que ja tenia una manera de treballar, torna a la seva drecera tan bon punt pot. Si una aplicació es deixa d'utilitzar, hi ha un error de disseny: una aplicació ha de simplificar la feina de qui l'utilitza, no crear-li una de nova.

Amb intel·ligència artificial això és encara més cert, perquè l'aplicació toca processos que fins ara feien persones amb criteri: recollir una comanda, revisar un expedient, preparar un document. Integrar-la a l'empresa (en com treballa de debò cada persona, amb les seves excepcions i els seus costums) és la part més complexa de tot el projecte, i és on es decideix si l'utilitzen els empleats i els clients o si s'oblida. Per què passa això, i què canvia amb l'IA, ho expliquem a per què les aplicacions tradicionals no aconsegueixen que els clients les utilitzin.

Un enginyer acabat de sortir de la universitat pot programar molt bé i no haver vist mai com entra una comanda en una distribuïdora, com es tanca un mes en una assessoria o què fa un encarregat d'obra a les set del matí. No és un defecte seu: aquest coneixement no s'aprèn programant. I sense ell, el projecte construeix exactament el que se li va demanar, que gairebé mai és el que l'empresa necessitava.

Què fa diferent un consultor que coneix el negoci

La diferència es veu a la primera conversa, en les preguntes. Abans de parlar de tecnologia, qui coneix com funciona una empresa pregunta pel negoci:

• Què té valor aquí? Què genera els diners, què els fa perdre i quin procés, si millora, es nota al compte de resultats. L'IA va allà, no on és més vistosa.
• Qui fa què, i per què així? Cada pas d'un procés té una raó, de vegades bona i de vegades heretada. Distingir-les evita automatitzar un error.
• On es perd el temps de debò? No on diu l'organigrama: on algú tecleja dues vegades, espera una resposta o busca una dada en tres pantalles.
• Quina drecera té avui cada persona? Un full, una trucada, una foto per WhatsApp. La drecera és informació: diu què sobra a l'eina actual i què ha de fer la nova per guanyar.
• Què fa avui el teu client, i què li costaria canviar? Si demana per telèfon i àudio, l'aplicació hi entra per aquí, no l'obliga a aprendre un catàleg.
• Quina excepció és en realitat la norma? La tarifa negociada, la comanda fora de ruta, l'expedient que no encaixa. Un estàndard les ignora; un disseny a mida comença per elles.
• Què pot i què no pot fer el teu sistema de gestió? Abans de prometre una integració, cal saber per on deixa entrar el fabricant.
• Què exigeix la norma en aquest cas? Dades personals, transparència amb el client, supervisió humana. És feina de disseny, no una clàusula al final.

Amb aquestes respostes, l'aplicació es dissenya per treure feina, no per afegir-ne. I això és el que decideix que la gent l'utilitzi: que li resolgui problemes en lloc de crear-n'hi, i no pas que sigui bonica ni que porti el model més nou.

Per què el negoci dirigeix el desenvolupament, i no al revés

En molts projectes passa al revés de com hauria de ser: la part tècnica decideix les funcions que sap construir i el negoci s'hi adapta. A Tecnea l'anàlisi del negoci va primer i es documenta (el mapa del procés, què té valor, les excepcions que són la norma, la drecera de cada persona i el criteri d'adopció) i aquest document és el que dirigeix el desenvolupament: l'equip tècnic construeix a partir del que necessita l'empresa, i quan hi ha un dubte, guanya el negoci. Així el que s'aprèn en l'anàlisi arriba al codi, i no es perd pel camí.

Tecnea va néixer el 2016, però el know-how del seu equip ve de més de vint anys treballant en sistemes de gestió, processos i direcció en empreses de diferents sectors i països. És el que permet mirar una empresa sencera i no només la part que es programarà: saber què té valor, què es pot tocar i què no, i com reaccionarà cada persona quan canviï la seva manera de treballar. És una anàlisi global i documentada del negoci, amb la tecnologia com a eina i un equip que la construeix a partir d'ella.

Com es dissenya l'adopció, i com es mesura

L'adopció no s'aconsegueix amb formació ni amb insistència. S'aconsegueix dissenyant-la, i això és el que fem en cada projecte:

1. 1Entrar pel canal que ja fan servir. Si els teus clients escriuen per WhatsApp i els teus empleats fan fotos dels albarans, l'aplicació ho accepta. Ningú ha d'aprendre a fer el que ja fa.
2. 2Parlar amb el vocabulari de cadascú. «La garrafa de cinc», «el de sempre», l'abreviatura de l'encarregat. El sistema aprèn els noms de les coses; no obliga ningú a fer servir els del catàleg.
3. 3Decidir què passa amb les excepcions abans de començar. Quines es resolen en la conversa, quines passen a una persona i quines no s'automatitzen mai. És el que evita que la primera excepció trenqui la confiança.
4. 4Treure, no afegir. Si una pantalla nova no elimina un pas antic, sobra. La mesura d'èxit és quantes coses deixa de fer la persona, no quantes funcions té l'aplicació.
5. 5Mesurar a la prova de concepte, amb casos reals. Quin percentatge de comandes, documents o consultes passaria sense intervenció, i quanta gent torna a utilitzar-la a la segona vegada. Amb aquest número es decideix si es continua; sense ell, «adopció» és una paraula.

Dit en una frase: l'objectiu és que empleats i clients vulguin utilitzar l'aplicació perquè els resol problemes i no els en crea cap. Això no es promet en una proposta; es comprova a la prova de concepte i es mesura després.

Per a qui és això

Per a empreses que volen una aplicació que s'utilitzi, no un informe que s'arxivi: aquí l'anàlisi acaba en una aplicació funcionant amb casos reals de la teva empresa. I si el que necessites és només un estudi estratègic, o un producte que ja existeix, t'ho direm a la primera conversa.

El que fem, i és pel que demanem que ens jutgin, és anàlisi de negoci amb la tecnologia al darrere: documentada, dirigint el desenvolupament, i amb un equip que construeix i manté l'aplicació a partir d'ella, en projectes d'entre 5.000 i 20.000 € amb una prova de concepte des de 850 € per veure-ho abans de comprometre res.

Com comprovar-ho abans de contractar ningú

Cinc preguntes que convé fer per escrit a qualsevol proveïdor, nosaltres inclosos, i guardar la resposta:

1. 1Qui analitzarà el meu procés, i quina experiència té en empreses com la meva? Si la resposta és un perfil tècnic sense experiència de negoci, o un comercial que després desapareix, el disseny sortirà d'un document.
2. 2L'anàlisi del negoci queda documentada i dirigeix el desenvolupament, o és la part tècnica la que decideix les funcions i el negoci s'hi adapta? És la diferència entre una aplicació que treu feina i una que n'afegeix.
3. 3Com mesurareu l'adopció, i quan? Si no hi ha un número abans de comprometre el projecte, no hi ha manera de saber si funciona.
4. 4Què passa amb les excepcions? Qui respon «l'IA les resol» no ha vist una empresa per dins.
5. 5Què em demanareu a mi? Un projecte seriós necessita hores de la persona que coneix el procés. Qui no les demana, no entendrà el negoci.

Si prefereixes començar per saber si necessites un desenvolupament o un producte, programari a mida o producte de catàleg ho resol en cinc minuts. I si el dubte és si la teva empresa necessita personal tècnic per a això, no cal un departament d'informàtica.