Software estàndard o a mida per a la teva empresa

El debat sobre software estàndard o a mida sol començar després d'una demostració. L'eina sembla encaixar fins que algú pregunta per una tarifa especial, una aprovació o aquell informe que creua dades de tres departaments. La resposta és que es pot resoldre, tot i que encara no queda clar qui ho farà ni quanta feina suposarà cada mes.

També passa a l'inrevés: es planteja desenvolupar una aplicació per a un procés que una eina existent resoldria amb una configuració raonable. És fàcil confondre una manera de treballar molt arrelada amb una necessitat que realment diferencia el negoci.

Abans de triar, convé separar totes dues coses. Hi ha hàbits que val la pena canviar i regles que el software ha de respectar perquè afecten el servei, els compromisos comercials o el control de l'operació.

La decisió comença pel procés

Tria un recorregut concret, des que entra una sol·licitud fins que es dona per acabada. Descriu qui hi intervé, quina informació necessita i què passa quan tot va bé. Després afegeix-hi les excepcions que l'equip resol de debò: una correcció, una aprovació pendent, una devolució o una dada que arriba tard.

Aquest recorregut permet avaluar una eina amb més criteri que una llista de mòduls. «Té facturació» diu poc si les condicions de la teva empresa exigeixen revisar conceptes abans d'emetre, agrupar operacions o conservar una relació precisa amb la feina feta.

No totes les diferències justifiquen desenvolupament. Canviar l'ordre d'una pantalla o adoptar una nomenclatura comuna pot simplificar l'operació. En canvi, traslladar una comprovació essencial a un full paral·lel pot deixar intacte el problema que pretenies resoldre.

La pregunta útil és quanta feina queda fora del sistema i quines conseqüències té. Una excepció poc freqüent es pot assumir manualment. Una revisió que es repeteix cada dia i depèn d'una sola persona mereix una altra anàlisi.

Quan una eina existent encaixa

Una solució estàndard és una bona candidata quan cobreix el procés principal, permet configurar les diferències rellevants i l'equip la pot utilitzar sense mantenir un sistema paral·lel. El valor és aprofitar una base que ja existeix i concentrar l'esforç a implantar-la bé.

Implantar també és feina. Cal netejar dades, decidir permisos, formar l'equip i comprovar que els informes reflecteixen l'operació. La quota d'ús no substitueix aquestes tasques, encara que el producte funcioni correctament des del primer dia.

Demana que la demostració recorri un exemple teu. Si una necessitat depèn d'una extensió, confirma quina part resol el producte, quina aporta l'extensió i qui manté la combinació. Una resposta concreta pot convertir una limitació aparent en una solució perfectament raonable.

També convé acceptar un límit d'abast. Si el primer objectiu és ordenar les sol·licituds d'un equip, no necessites resoldre d'entrada totes les relacions amb comptabilitat, clients i proveïdors. L'eina pot encaixar en aquesta primera fase encara que no s'hagi de convertir en el sistema central de l'empresa.

Integrar pot resoldre el buit

De vegades les eines fan bé la feina per separat, però les persones fan de connexió entre elles. Copien dades, comproven estats i tornen a introduir allò que ja existeix en un altre lloc. En aquest escenari, substituir-ho tot pot afegir més risc que valor.

Una integració permet conservar els sistemes que funcionen i automatitzar una part de l'intercanvi. Per saber si és viable cal revisar quines dades exposa cada eina, quines operacions permet i quines limitacions imposa. Tenir una API, una interfície perquè dos programes es comuniquin, és el començament de la revisió.

És especialment important decidir quin sistema mana sobre cada dada. Si el preu es manté en dos llocs, cal resoldre quin preval i com es detecta una discrepància. També ha de quedar clar què passa si una connexió falla: si es reintenta, si algú rep un avís i si una operació es podria duplicar.

Aquesta feina forma part del desenvolupament de software a mida, encara que el resultat sigui una connexió petita en lloc d'una aplicació nova. El seu abast s'hauria de descriure amb la mateixa cura.

Què justifica construir una eina pròpia

El desenvolupament propi guanya sentit quan les regles rellevants no encaixen en les alternatives avaluades, quan l'adaptació acumula feina manual o quan el procés necessita evolucionar amb una llibertat que aquestes eines no ofereixen.

L'avantatge és poder dissenyar el sistema al voltant de l'operació. La responsabilitat és decidir què construir, validar que resol el problema i sostenir-ho després. No n'hi ha prou amb lliurar pantalles: algú ha de poder comprendre el funcionament, mantenir-lo i acompanyar els canvis del negoci.

A Quiralis, el cas publicat descriu una plataforma que connecta actes mèdics, autoritzacions i facturació. La substitució d'un sistema antic es va plantejar per fases, mantenint la convivència amb els processos anteriors mentre es validava cada àrea.

Aquest cas il·lustra una decisió d'adaptació i transició. No vol dir que qualsevol centre necessiti reproduir-ne la plataforma ni que construir des de zero sigui sempre la millor resposta. La necessitat depèn d'allò que ja funciona, d'allò que falta i de les condicions concretes de l'operació.

Compara la feina de diversos anys

Per valorar les opcions, el pressupost inicial és insuficient. Necessites considerar implantació, llicències o infraestructura, integracions, suport, formació i canvis previsibles. Inclou-hi també la feina manual que l'equip continuarà fent després del lliurament.

Un software propi pot requerir més inversió inicial i, tot i així, encaixar en un procés específic. Una eina estàndard pot continuar sent l'opció més econòmica encara que tingui una quota recurrent. Cap d'aquestes conclusions s'obté només llegint la primera factura.

La comparació millora si totes les propostes cobreixen el mateix abast. Un pressupost amb migració, proves i suport no és directament comparable amb un altre que lliura únicament la configuració inicial. Demana que s'expliquin les exclusions, perquè solen contenir una part important de la diferència.

Evita convertir l'anàlisi en una predicció exacta de l'estalvi. És més útil treballar amb escenaris i supòsits visibles: quantes persones fan la tasca, amb quina freqüència, quant temps hi dediquen ara i quina part de la feina continuarà necessitant intervenció.

Poder canviar de proveïdor també compta

Abans de contractar, revisa quines dades podràs exportar, en quin format i quines relacions conservaran. Una descàrrega que conté registres però perd documents o vincles pot ser insuficient per a una migració futura.

En un desenvolupament propi, acorda l'accés al codi, la documentació necessària i la gestió dels comptes d'infraestructura. Tenir una còpia del repositori ajuda, però el relleu també necessita saber com es desplega, com es recuperen les dades i quins serveis externs hi intervenen.

En un producte estàndard, comprova les condicions de sortida i les restriccions d'integració. La dependència no desapareix per utilitzar una modalitat o l'altra. Canvia de forma i convé entendre-la abans que es converteixi en un problema.

Una primera fase que permeti decidir millor

Si encara hi ha massa incògnites, defineix una fase d'anàlisi amb un lliurament concret: procés i excepcions, dades necessàries, alternatives avaluades i una proposta d'abast. Una prova acotada pot servir per comprovar el punt més incert, sempre que se sàpiga quina decisió permetrà prendre.

Quan ja existeix una aplicació pròpia, revisa també si n'hi ha prou amb millorar-ne una part. La tria entre refactoritzar o reescriure respon a una altra pregunta: quant del sistema actual convé conservar. No hauria de quedar resolta per endavant per la preferència de qui presenta la proposta.

El software que encaixa deixa que l'equip treballi amb menys fricció i permet entendre què passa quan apareix una excepció. Arribar a aquest resultat exigeix conèixer l'operació prou bé per distingir allò que val la pena canviar d'allò que necessites preservar.