La resposta curta és que ha de participar-hi un equip amb autoritat, coneixement i capacitat d'execució. La resposta llarga és més interessant: participar no vol dir assistir a reunions. Vol dir tenir un mandat clar per decidir sobre l'abast, el pressupost, l'experiència d'usuari, la seguretat i la continuïtat del negoci. Un projecte de programari empresarial és un sistema sociotècnic; si només hi participen enginyers, el resultat serà tècnicament correcte però desconnectat de l'operació. Si només hi participen directius, serà un projecte ple d'intencions però sense validació real. L'equilibri és en una governança que representi tots els angles.
Primer, el patrocinador executiu. No és la persona que signa el pressupost i desapareix. És qui té autoritat per desbloquejar conflictes entre departaments, aprovar canvis d'abast i comunicar la prioritat estratègica del projecte. Sense un patrocinador amb poder real, les decisions es posposen i l'equip perd legitimitat. No ha de saber programar, ha de saber governar.
Segon, el responsable de producte o procés. Aquest rol és el dipositari de la visió del negoci. A diferència del patrocinador, la seva feina és operativa: prioritza el backlog, defineix els criteris d'acceptació, resol dubtes funcionals i accepta o rebutja els lliuraments. En projectes de desenvolupament d'aplicacions a mida, aquest rol és essencial perquè les necessitats reals no són en un manual; són en com treballen les persones, en les excepcions que no es documenten i en les mètriques que l'empresa vol moure. El responsable de producte ha de tenir temps dedicat; no pot ser un 'director de màrqueting que dona un cop de mà'.
Tercer, els usuaris de negoci. Sovint se'ls consulta al principi i al final, però no durant el procés. Això genera un desajust clàssic: el programari compleix el que hi ha escrit als requisits, però no el que l'operació necessita. Els usuaris han de participar en la definició d'històries d'usuari, en les proves funcionals i en la formació de primers adoptants. No tots poden ser a totes les reunions; es poden crear comunitats de pràctica o grups de referència amb un representant per àrea. L'important és que el diàleg sigui continu, no un esdeveniment aïllat.
El grup següent és el de tecnologia i arquitectura. Inclou enginyers de programari, administradors de sistemes, arquitectes de dades i especialistes en integració. El seu paper és transformar les necessitats en una solució viable, sostenible i segura. En el món actual, aquest grup ha de prendre decisions sobre cloud AWS/Azure, ciberseguretat i interoperabilitat amb eines de reporting com ara BI/Power BI. Si l'arquitectura es decideix després de validar l'abast, el projecte pot encarir-se. Per això els tècnics han de ser presents des de l'inici, no quan ja s'ha promès una data.
Un altre perfil clau és el responsable de dades. Moltes solucions de programari empresarial depenen de dades mestres, dades d'operacions i dades financeres. Si no hi ha algú que conegui la semàntica de cada camp, el seu origen i les regles de qualitat, la solució produirà informes brillants però poc fiables. La participació del responsable de dades és necessària per dissenyar el model de dades, evitar duplicitats i garantir que els indicadors que veurà la direcció siguin auditables. A més, la seva feina es connecta amb la ciberseguretat: saber qui pot accedir a cada dada, durant quant de temps i amb quina justificació.
Aquí és on entren els agents d'IA. Quan una solució incorpora intel·ligència artificial, l'equip del projecte necessita definir no només l'algorisme, sinó el llindar de confiança, el circuit de retroalimentació i el mecanisme d'intervenció humana. La IA no és un component que s'afegeix al final; canvia la manera de capturar dades, d'entrenar models i de mesurar errors. En aquest context, la participació dels responsables de negoci és encara més important, perquè són els únics que poden dir si una decisió automatitzada té sentit en el món real. Els agents d'IA han d'operar amb regles clares, i aquestes regles no les defineix només TI: les defineixen negoci, legal i operacions en conjunt.
També és imprescindible la funció de compliment i riscos. Depenent del sector, pot incloure protecció de dades, compliment legal, auditoria interna o prevenció de frau. Involucrar aquestes persones des del principi evita que al final es descobreixi que el disseny no compleix una normativa. No es tracta que participin en totes les reunions tècniques; es tracta que validin els fluxos crítics, les polítiques de privadesa i els registres d'activitat. Com més aviat es detecti un incompliment, més barat serà corregir-lo. L'autoritat de l'àrea de riscos ha de ser real; un projecte de programari no pot afeblir els controls interns.
La gestió del canvi és una altra funció que sovint s'oblida. Les solucions de programari empresarial no acaben quan es fa el desplegament; comencen quan les persones les fan servir. Un equip de gestió del canvi ajuda a identificar resistències, dissenyar formació, crear FAQ, recollir incidències i ajustar el sistema en els primers mesos. Aquesta funció ha d'estar connectada amb els usuaris de negoci, però també amb l'equip tècnic per al feedback continu. L'adopció no és un problema de comunicació; és un problema de disseny, i s'ha de tractar com a part de la feina de producte.
A Q2BSTUDIO, com a empresa de desenvolupament de programari i tecnologia, treballem amb una combinació d'aquests perfils en cada projecte. Ajudem les organitzacions a configurar un comitè de direcció reduït, a definir els ritmes de lliurament i a establir criteris d'acceptació mesurables. També aportem coneixement especialitzat en aplicacions a mida, automatització de processos, cloud AWS/Azure, ciberseguretat, BI/Power BI i agents d'IA. El nostre paper no és substituir els equips interns, sinó complementar-los amb una mirada tècnica i estratègica que connecti la tecnologia amb els resultats de negoci.
La conclusió és que no existeix una plantilla universal de participants. Existeix, en canvi, un principi universal: tota persona que tingui informació, risc o responsabilitat sobre un resultat ha de tenir un mecanisme per aportar aquesta informació o per vetar decisions. La mida del grup pot variar, però els rols no poden quedar buits. Si un projecte no té patrocinador, algú pagarà la factura sense saber per què. Si no té responsable de producte, tothom decidirà i ningú respondrà. Si no té usuaris reals, l'eina serà bonica a la demo i inútil al dia a dia. Si no té arquitectura, el deute tècnic es convertirà en una barrera per créixer. I si no té supervisió ètica i normativa, la velocitat del projecte es convertirà en un risc per a l'organització.
Així doncs, quan una empresa es pregunta qui ha de participar en solucions de programari empresarial, la resposta correcta no és un nom, sinó un sistema de rols amb responsabilitats clares. Aquest sistema ha d'incloure la direcció, el negoci, la tecnologia, les dades, els usuaris finals i les funcions de control. I s'ha de mantenir viu durant tot el cicle de vida del projecte, perquè una solució de programari empresarial sempre està en evolució. La participació no és un esdeveniment; és l'estructura que fa que el programari funcioni com a part de l'empresa.
