<p>On the Tuesday that the Mar Abierto cooperative decided to change platforms, there was no attack. The difficulty appeared earlier: no one could say precisely what would stop if the old service failed at nine in the morning. Delivery shifts were checked there, payments were reconciled there, and urgent notices travelled through a channel tied to the same account. Each component had looked small when it was purchased. Together, they had made one tool a condition for the working day to begin.</p>
<p>That is what has grown with digital dependence: not only the number of applications, but the number of ordinary relationships that pass through them. An outage is no longer just a screen that will not load. It may leave one person unsure which shift to attend, another unable to confirm a payment, and a team without a shared way to say that an incident exists. Looking at those relationships is more useful than repeating that everything is “in the cloud,” because it helps decide which continuity is worth preparing.</p>
Making the context clear#
<h2>Start the map with an ordinary day</h2>
<p>The cooperative brought together a delivery worker, the person who kept the accounts, a customer-support colleague, and the technical administrator. They were not asked for a systems inventory. They were asked to reconstruct a normal Wednesday from eight until two. The delivery worker opened the calendar to learn the route; support updated a changed address; accounts checked that a charge was not duplicated; and the coordinator sent a shift change. The walk-through showed that one account sustained decisions made by people who never met in the same room.</p>
What changes in practice#
<p><strong>A continuity map does not list software; it shows which concrete promise cannot be kept when a connection fails.</strong> In this case, the promise differed with the observer. For a customer, it was receiving an answer. For the delivery worker, it was knowing where to go. For the cooperative, it was recording a delivery and collecting payment later. The tool was shared, but the consequences were not. Separating them prevents a technical priority from hiding the people who carry the delay.</p>
<p>The group drew simple arrows among an action, a piece of data, a person, and a channel. When they asked what happened if the calendar would not open, real alternatives emerged: a printed list for routes already assigned and phone calls for critical changes. When they asked about payments, the answer was different: orders could be noted down, but amounts could not be confirmed and a refund could not be detected until access returned. The contrast showed where a decision should be prepared, rather than where everything should be copied indiscriminately.</p>
Deciding with information#
<h2>Migration is not merely moving an account</h2>
<p>A migration is often presented as a technical project: export data, create users, press a button, and close the old contract. In practice it changes working agreements. If shifts are assigned differently, someone must know who corrects an absence. If payments move to a new screen, accounts must be able to compare an amount before approving it. If communication no longer relies on an informal group, the team needs a channel that works even when nobody remembers an administrative password.</p>
Reviewing and adjusting#
<p>For that reason, Mar Abierto did not begin by asking what features the new provider offered. It began with three questions: which task cannot wait until tomorrow, what information does that task need to be done properly, and who can choose an alternative without putting somebody else at risk? The answers separated essential services from conveniences. That day’s shifts and messages about a delivery were urgent. The complete history of conversations could wait. The distinction gave later tests a clear purpose.</p>
<p><strong>Continuity relies on visible responsibilities, not on the hope that an expert will be available.</strong> The cooperative appointed one person responsible for the shift list, another for a temporary payment record, and a third for the message to customers. Each had a substitute, a record format, and a time to review what had been written down. It was not a heroic plan. It was a way to keep an outage from becoming silence, improvisation, and data scattered across personal phones.</p>
<p>That division also revealed an important boundary. Some payment data could not be moved to a shared spreadsheet or sent through messaging. The alternative had to preserve privacy while allowing work to continue. The team agreed to record only minimal references, confirm amounts through an authorized channel, and reconcile later with the official source. Continuity does not mean reproducing every operation outside the system; it means preserving the service without creating a problem larger than the original interruption.</p>
<h2>Rehearse the connections, not just the outage</h2>
<p>Before signing the migration, Mar Abierto ran a two-hour exercise. They simulated the previous provider being unavailable while the day still contained deliveries, questions, and payments. The first surprise was that the support number appeared on the same page that was failing. The second was that the person able to export a shift did not know the criterion the delivery team used to prioritize a change. Neither issue was a spectacular breach; both could leave someone waiting without an explanation.</p>
<p>The exercise was not meant to prove that the plan was perfect. It was meant to discover where relationships were hidden. After each blockage, the team wrote one sentence: “to do X, we need to speak with Y using Z.” That sentence forced them to name a person, an action, and a channel, rather than file a vague label such as “review communications.” By the end, they had five specific corrections: print on-call contacts, define an incident message, separate payment permissions, keep a route template, and name who confirms the return to normal service.</p>
<p><strong>A continuity measure is credible when it can be walked through under the pressure and constraints of a real day.</strong> If it works only when its designer is present, it is not a collective capability. The cooperative repeated the exercise during an afternoon shift, with a different coordinator and an unexpected address change. It took longer than expected, but they found an ambiguous instruction before needing it for real. That controlled delay was worth more than a contractual availability promise.</p>
<h2>A decision for next week</h2>
<p>The map should not end up stored in a folder. Mar Abierto chose to revisit it whenever it added an integration, changed provider, or introduced a task dependent on an automatic notification. They do not start from zero: they follow the actions that sustain shifts, payments, and communication, ask which new connection has been created, and check whether a proportionate alternative still exists. In this way the map becomes a maintenance conversation rather than a ceremonial document.</p>
<p>For a small team, the next step can be very concrete: choose an upcoming day and draw three arrows for one essential service. Who starts the task? Which tool connects the other people? What happens if that connection fails for four hours? The answer does not require perfect infrastructure. It requires naming the relationship that was invisible, choosing a safe alternative, and assigning someone to test it. Digital dependence grows as these relationships accumulate; our capacity can grow too when we begin to see and care for them.</p>
