<p>El dimarts que la cooperativa Mar Obert va decidir canviar de plataforma no hi va haver cap atac. El dubte va aparèixer abans: ningú no podia explicar amb precisió què s'aturaria si el servei antic deixava de respondre a les nou del matí. Els torns de repartiment es consultaven allí, els cobraments es conciliaven des d'allí i els avisos urgents viatjaven per un canal connectat al mateix compte. Cada peça havia semblat petita quan es va contractar. Juntes havien convertit una eina en una condició perquè la jornada pogués començar.</p>
<p>Això és el que ha crescut amb la dependència digital: no solament la quantitat d'aplicacions, sinó el nombre de relacions quotidianes que hi circulen. Una caiguda ja no és només una pantalla que no carrega. Pot deixar una persona sense saber a quin torn ha d'anar, una altra sense confirmar un pagament i un equip sense una manera compartida d'avisar que la incidència existeix. Mirar aquestes relacions és més útil que repetir que “tot és al núvol”, perquè permet decidir quina continuïtat cal preparar.</p>
Posar el context en clar#
<h2>El mapa comença per una jornada ordinària</h2>
<p>La cooperativa va reunir una repartidora, la persona que portava la comptabilitat, algú d'atenció als clients i l'administradora tècnica. No els va demanar un inventari de sistemes. Els va demanar reconstruir un dimecres normal, de les vuit a les dues. La repartidora va obrir el calendari per saber la ruta; atenció va actualitzar un canvi d'adreça; comptabilitat va comprovar que un cobrament no estigués duplicat; i la coordinadora va comunicar una modificació de torn. El recorregut va mostrar que un mateix compte sostenia decisions de persones que mai no coincidien a la mateixa sala.</p>
Allò que canvia a la pràctica#
<p><strong>Un mapa de continuïtat no enumera programes: mostra quina promesa concreta queda sense complir quan falla un vincle.</strong> En aquest cas, la promesa era diferent segons qui la mirava. Per al client era rebre una resposta. Per a la repartidora era saber on anar. Per a la cooperativa era poder registrar un lliurament i cobrar-lo després. L'eina era comuna, però les conseqüències no. Separar-les evita que una prioritat tècnica amagui les persones que suporten el retard.</p>
<p>El grup va dibuixar fletxes senzilles entre acció, dada, persona i canal. Quan va preguntar què passava si el calendari no s'obria, van aparèixer alternatives reals: una llista impresa per a les rutes ja assignades i trucades per als canvis crítics. Quan va preguntar pels pagaments, la resposta va ser diferent: podien anotar comandes, però no confirmar imports ni detectar una devolució fins a recuperar l'accés. El contrast va indicar on convenia preparar una decisió, no una còpia indiscriminada de tot.</p>
Decidir amb informació#
<h2>Migrar no és simplement traslladar un compte</h2>
<p>Una migració sovint es presenta com un projecte tècnic: exportar dades, crear usuaris, prémer un botó i tancar el contracte anterior. En realitat transforma acords de treball. Si els torns s'assignen d'una altra manera, algú ha de saber qui corregeix una absència. Si els cobraments canvien de pantalla, comptabilitat ha de poder comparar un import abans d'autoritzar-lo. Si la comunicació deixa de dependre d'un grup informal, l'equip necessita un canal que funcioni fins i tot quan ningú recorda una contrasenya administrativa.</p>
Revisar i ajustar#
<p>Per això Mar Obert no va començar preguntant quines funcions oferia el proveïdor nou. Va començar per tres preguntes: quina tasca no pot esperar fins demà?, quina informació necessita aquesta tasca per fer-se bé?, i qui pot decidir una alternativa sense posar ningú altre en risc? Les respostes van separar els serveis essencials de les comoditats. Els torns del dia i els missatges sobre un lliurament eren urgents. L'historial complet de converses podia esperar. La distinció va donar sentit a les proves posteriors.</p>
<p><strong>La continuïtat depèn de responsabilitats visibles, no de l'esperança que una persona experta estigui disponible.</strong> La cooperativa va assignar una responsable de la llista de torns, una altra del registre temporal de cobraments i una tercera del missatge als clients. Cadascuna tenia una substituta, un format de registre i una hora per revisar allò anotat. No era un pla heroic. Era una manera d'evitar que una caiguda es convertís en silenci, improvisació i dades escampades per telèfons personals.</p>
<p>El repartiment també va revelar un límit important. Algunes dades de pagament no es podien traslladar a un full compartit ni circular per missatgeria. L'alternativa havia de conservar la privacitat i permetre treballar alhora. L'equip va acordar anotar només referències mínimes, confirmar imports per un canal autoritzat i conciliar després amb la font oficial. Continuïtat no vol dir reproduir cada operació fora del sistema; vol dir mantenir el servei sense crear un problema més gran que la interrupció inicial.</p>
<h2>Assajar les connexions, no sols la caiguda</h2>
<p>Abans de signar la migració, Mar Obert va fer un assaig de dues hores. Van simular que el proveïdor anterior no estava disponible, mentre el dia continuava tenint repartiments, preguntes i pagaments. La primera sorpresa va ser que el número d'atenció figurava a la mateixa pàgina que fallava. La segona, que la persona capaç d'exportar un torn no sabia quin criteri feia servir l'equip de repartiment per prioritzar una modificació. Cap de les dues coses era una bretxa espectacular; totes dues podien deixar algú esperant sense explicació.</p>
<p>L'assaig no pretenia demostrar que el pla fos perfecte. Pretenia descobrir on les relacions estaven amagades. Després de cada bloqueig, l'equip anotava una frase: “per fer X necessitem parlar amb Y utilitzant Z”. La frase obligava a identificar una persona, una acció i un canal, en lloc d'arxivar una etiqueta genèrica com “revisar comunicacions”. Al final de la prova, tenien cinc correccions concretes: imprimir contactes de guàrdia, definir un missatge d'incidència, separar permisos de cobrament, guardar una plantilla de rutes i fixar qui confirma el retorn al servei normal.</p>
<p><strong>Una mesura de continuïtat és creïble quan es pot recórrer amb la pressió i les restriccions d'un dia real.</strong> Si només funciona quan hi és qui l'ha dissenyada, no és una capacitat col·lectiva. La cooperativa va repetir la prova en un torn de tarda, amb una altra persona coordinant i amb un canvi d'adreça inesperat. Van trigar més del previst, però van trobar una instrucció ambigua abans de necessitar-la de debò. Aquesta demora controlada va valer més que una promesa contractual sobre disponibilitat.</p>
<h2>Una decisió per a la setmana vinent</h2>
<p>El mapa no hauria d'acabar desat en una carpeta. Mar Obert va decidir revisar-lo cada vegada que afegís una integració, canviés de proveïdor o incorporés una tasca dependent d'una notificació automàtica. No ho revisen tot des de zero: recorren les accions que sostenen torns, cobraments i comunicació, pregunten quin vincle nou s'ha creat i comproven si encara existeix una alternativa proporcionada. Així el mapa esdevé una conversa de manteniment, no un document ceremonial.</p>
<p>Per a un equip petit, el pas següent pot ser molt concret: escollir una jornada propera i dibuixar tres fletxes per a un servei essencial. Qui inicia la tasca? Quina eina connecta les altres persones? Què passa si aquesta connexió falla durant quatre hores? La resposta no exigeix una infraestructura perfecta. Exigeix anomenar la relació que no es veia, decidir una alternativa segura i assignar algú que la provi. La dependència digital creix quan aquestes relacions s'acumulen; la capacitat també pot créixer quan comencem a veure-les i cuidar-les.</p>
