Modernitzar programari: errors que convé evitar abans de canviar el sistema

El programa continua funcionant, però cada canvi requereix fer marrades, hi ha dades duplicades i una part de l’equip manté tasques paral·leles en fulls de càlcul, correus o missatges. En aquest punt, modernitzar el programari sembla una decisió evident. La dificultat és decidir què has de conservar, què convé canviar i quin problema mereix resoldre’s primer.

Aquest article t’ajuda a reconèixer els errors que més comprometen una modernització. En acabar, podràs revisar la teva situació amb més criteri i decidir si necessites ajustar el sistema actual, substituir-ne una part o plantejar una solució nova.

Què es vol aconseguir en modernitzar programari

L’objectiu no hauria de ser tenir una eina més recent, sinó millorar una operació concreta. Pot tractar-se de reduir passos manuals, consultar informació sense dependre de diverses fonts, evitar errors en introduir dades o donar als clients i a l’equip un accés més clar a determinats processos.

Abans de parlar de tecnologia, separa tres nivells:

• Objectiu: què hauria de canviar al teu negoci o per a les persones que fan servir el sistema.
• Abast: quins processos, dades, usuaris i regles s’han d’incloure per aconseguir aquest canvi.
• Solució: com es durà a terme, ja sigui mitjançant una millora del programari actual, una integració, una eina estàndard o un desenvolupament específic.

Aquesta separació evita començar per una resposta tancada —per exemple, «necessitem una aplicació nova»— quan encara no s’ha definit bé el problema.

Errors freqüents en modernitzar programari

1. Començar per la tecnologia i no pel procés

Símptoma: la conversa gira de seguida al voltant de canviar de plataforma, refer pantalles o incorporar funcions, però no queda clar quina tasca falla ni qui la fa.

Causa: es confon el desgast visible del programa amb la causa operativa. Una interfície antiga pot resultar incòmoda, però també pot amagar un procés amb passos innecessaris, regles poc definides o responsabilitats repartides sense criteri.

Conseqüència: pots traslladar el mateix problema a un sistema nou. L’equip s’haurà d’adaptar a una altra eina sense que desapareguin les esperes, les dades incompletes o les duplicitats.

Correcció: descriu primer el recorregut real d’una tasca rellevant. Indica qui inicia l’acció, quina informació necessita, quines decisions pren, on es produeixen excepcions i com acaba el procés. Després podràs valorar quina part ha de canviar i quina només necessita una millora puntual.

2. Voler substituir-ho tot de cop

Símptoma: el projecte aplega totes les necessitats pendents: gestió de clients, comandes, documents, informes, permisos, automatitzacions i noves integracions.

Causa: s’aprofita la modernització per intentar resoldre tots els problemes acumulats. És comprensible, però tractar cada petició com a prioritària impedeix distingir allò necessari del que pot esperar.

Conseqüència: l’abast es torna difícil de validar. També augmenta el risc que decisions rellevants quedin pendents fins a fases avançades, quan canviar una funció afecta altres parts del sistema.

Correcció: classifica cada necessitat en quatre grups: imprescindible per a la primera versió, desitjable, futura o fora d’abast. Per a cada funció, pregunta’t quin objectiu dona suport, qui la farà servir, què passarà si s’ajorna i com comprovaràs que funciona.

3. Donar per feta la migració de dades

Símptoma: es parla de «passar la informació» al sistema nou sense inventari ni criteris sobre quines dades continuen sent útils.

Causa: es tracta la migració com una tasca tècnica automàtica. Tanmateix, les dades poden estar repartides entre programes, arxius, formats diferents o registres incomplets.

Conseqüència: pots traslladar informació duplicada, desactualitzada o difícil d’interpretar. També poden sorgir dubtes sobre camps, historials, documents associats i responsables quan el canvi ja està en marxa.

Correcció: prepara un inventari abans de triar la solució. Identifica l’origen de cada dada, el seu format, el seu responsable, el seu ús actual i si s’ha de conservar, corregir, arxivar o descartar. Defineix també què s’ha de comprovar abans de donar per vàlida la migració.

4. Ignorar qui fa servir el programari cada dia

Símptoma: el sistema es decideix a partir d’una necessitat general de direcció, però les persones que registren, consulten o corregeixen la informació no han participat en la definició.

Causa: es pressuposa que tothom fa servir el programa de la mateixa manera. A la pràctica, una persona d’administració, una responsable d’operacions i un usuari extern poden necessitar permisos, dades i recorreguts diferents.

Conseqüència: l’eina pot semblar correcta sobre el paper i, tot i així, generar dreceres informals. Tornen les notes, els missatges i els fitxers paral·lels perquè el flux previst no encaixa amb la feina real.

Correcció: identifica perfils d’usuari i tasques concretes. No n’hi ha prou de dir «equip intern» o «clients». Defineix què pot veure, crear, modificar o aprovar cada perfil, així com els casos en què necessita ajuda o una alternativa.

5. Integrar eines sense definir el flux d’informació

Símptoma: se sol·licita connectar el programari nou amb facturació, correu, inventari o una altra plataforma, però no es concreta quines dades circulen, en quina direcció ni què passa si la connexió falla.

Causa: s’entén una integració com un simple enllaç entre dues eines. En realitat, cal decidir qui té la dada principal, quan s’actualitza, quines regles s’apliquen i com es detecten els errors.

Conseqüència: pots crear informació incoherent entre sistemes o dependre de processos manuals per corregir incidències. A més, una integració pot condicionar l’abast i el manteniment més del que s’esperava.

Correcció: documenta cada connexió amb preguntes senzilles: quin sistema envia la informació, quin la rep, quins camps hi intervenen, quan se sincronitzen i qui revisa una incidència. Si una eina externa imposa límits o canvia les seves condicions, convé validar-ho abans de prendre una decisió tècnica.

6. No definir què significa que una funció estigui acabada

Símptoma: els requisits s’expressen amb paraules com «intuïtiu», «complet», «ràpid» o «fàcil d’utilitzar», sense una situació concreta que permeti comprovar-les.

Causa: manquen criteris d’acceptació: condicions observables que indiquen si una funció compleix allò acordat.

Conseqüència: les revisions es basen en impressions diferents. Allò que per a tu estava inclòs pot interpretar-se com una millora posterior, i una funció aparentment acabada pot no cobrir errors, permisos o casos excepcionals.

Correcció: converteix cada requisit rellevant en una comprovació. Per exemple, en un cas hipotètic: «quan una persona autoritzada registra una comanda amb tots els camps obligatoris, el sistema mostra una confirmació i deixa la comanda disponible per al perfil que l’ha de gestionar». Afegeix què ha de passar si falta una dada o si l’usuari no té permís.

7. Oblidar qui mantindrà el sistema després

Símptoma: la conversa se centra en la posada en marxa, però no en actualitzacions, accessos, documentació, incidències o canvis futurs.

Causa: es considera la modernització com un lliurament tancat. Tanmateix, el programari forma part d’una operació que pot canviar: apareixen serveis, rols, regles o eines externes nous.

Conseqüència: una modificació petita pot convertir-se en una decisió incerta perquè ningú no sap què depèn de què, qui conserva els accessos o com actualitzar informació sense afectar el funcionament.

Correcció: defineix des de l’inici qui administrarà el sistema, quines persones necessiten formació, quina documentació ha d’existir i quin tipus de canvis preveus. També convé aclarir la titularitat i el control dels comptes, les dades i els serveis de tercers.

Com prevenir aquests errors abans de decidir

No necessites tenir resolta la solució per preparar bé una modernització. Sí que cal fer visibles les decisions que poden alterar l’abast.

Comença amb un procés que tingui un impacte clar en la teva activitat. Reuneix les persones que el coneixen i descriu el punt de partida, les friccions i el resultat esperat. Després separa allò que saps d’allò que encara has de validar.

En particular, no donis per tancats aquests aspectes:

• la informació que s’ha de conservar i el seu estat real;
• els perfils que faran servir el sistema i els seus permisos;
• les regles, excepcions i aprovacions del procés;
• les eines que s’han de connectar;
• els elements que formen part d’una primera versió i els que poden esperar;
• la manera de comprovar que cada funció respon a la necessitat definida;
• la responsabilitat sobre manteniment, continguts, comptes i accessos.

Aquesta preparació no elimina tota la incertesa. Serveix perquè sigui explícita i es pugui decidir abans de convertir-la en un problema de desenvolupament.

Llista de comprovació per modernitzar programari

Fes servir aquesta llista abans d’aprovar una substitució, una millora o una solució nova:

• He definit el problema operatiu que vull resoldre sense partir d’una tecnologia concreta.
• Sé quin procés revisaré primer i qui hi intervé.
• He diferenciat l’objectiu, l’abast inicial i la possible solució.
• He classificat les funcionalitats entre imprescindibles, desitjables i futures.
• He identificat les dades existents, el seu origen i què cal fer-ne.
• He concretat perfils d’usuari, permisos i accions habituals.
• He descrit les integracions necessàries i el flux de dades de cadascuna.
• He definit com comprovaré les funcions rellevants, inclosos els errors i les excepcions.
• He assenyalat dependències externes, responsables d’aprovació i decisions pendents.
• He pensat qui administrarà, actualitzarà i mantindrà el sistema després.

Si no pots respondre a diversos punts, no vol dir que hagis d’aturar tota iniciativa. Vol dir que convé delimitar primer la incertesa abans de comprometre una solució concreta.

Pas següent

Quan el programari actual limita un procés important, no cal decidir immediatament entre refer-lo completament o conservar-lo. El pas següent raonable és ordenar el problema, l’abast i les dependències per valorar alternatives amb criteri.

Si vols contrastar quina part del teu sistema convé mantenir, millorar o replantejar, pots explicar el teu projecte d’aplicació o programari a mida a AVSISTEC.