Digital transformation support
In short: Digital change is about the way work is organised, not about the software you install. The value comes from understanding processes as they actually run, from the order in which things are tackled, and from the attention paid to the people who will have to work differently — all of which is settled before a tool is chosen, and often reduces the need for one.
"We are going digital" rarely means the same thing from one company to the next. For one, it means no longer retyping the same information into four places; for another, finally knowing where the open files stand; for a third, replacing a piece of software that has become unworkable without reproducing its flaws. What these situations have in common is not technical: it lies in processes that have piled up over time, that nobody has ever written down, and that everyone works around in their own way. This page describes what digital change actually covers, how an organisation is examined before it is modified, how a support assignment unfolds, the mistakes that come up most often, and the situations where the honest answer is to start nothing for now.
What digital change is, and why it is not a software purchase
In short: The word covers three undertakings of very different scale: replacing a physical support with a file, reorganising the sequence of steps, or making legible information that was not. None of the three is obtained by installing a product.
When a company announces that it is going digital, the phrase most often points to an intention to buy: a management system, a tracking tool, a shared workspace. Yet the purchase is the simplest and least decisive part. A tool does nothing by itself; it makes possible a way of working that still has to be decided, written down and adopted. It is that decision, not the licence, that produces the result. This explains an ordinary but instructive observation: two companies equipped with the same product get entirely unrelated benefits from it, because one changed how it works and the other simply transposed its old habits into a new interface.
Three undertakings of increasing scale hide behind the same word. The first is dematerialisation: the process stays identical, only the support changes. A document circulates as a file rather than a sheet of paper, it becomes readable from anywhere and stops getting lost. That is useful, it is quick to obtain, and it corrects nothing of what was already shaky — an incoherent sequence of steps stays incoherent, it merely circulates faster. The second undertaking is the reorganisation of the process itself: an approval disappears because it no longer protected anything, two steps merge, a piece of information is captured once at its source instead of being copied everywhere downstream. This touches roles and habits, which is why it is at once the most rewarding and the most difficult.
The third undertaking concerns what the organisation knows about itself: once information stops being scattered, questions that had gone unanswered become answerable — how many files are waiting, at which step they stall, which ones always come back for rework. It is no longer execution that changes, it is the decisions.
What is called change management is the real material of this work: habits formed by people who had good reasons to form them, roles that define everyone’s place, an implicit responsibility for data quality that nobody ever put into words, and trade-offs left unsettled for so long that the organisation has built itself around them. The software is the visible part and the easiest to order. What decides the outcome plays out in conversations with no screen in them: who approves what from now on, who answers when an exception arises, what the company agrees to stop doing.
It remains to say what the term does not cover. It is not an IT project handed to a supplier while the company carries on as before: knowledge of the processes belongs to those who run them, and no outside view replaces it — an outside view only makes it visible. Nor is it a permanent state reached once and for all; it is a series of successive undertakings, each with an identifiable beginning and end. And it is not necessarily a matter of new tools: organisations frequently already own features they have paid for and never switched on, and a mapping exercise is sometimes enough to make them useful.
How an organisation is examined before it is modified
In short: Mapping a process means writing down what actually happens, not what the procedure says. Friction then shows itself through constant signs: information retyped, a file waiting on a person, an exception handled from memory, a check redone out of mistrust.
A process is a sequence of steps running from a triggering event to a result: a request comes in, something happens, a client receives an answer or an invoice goes out. Mapping it means writing that sequence as it actually unfolds, with the people involved, the supports they genuinely use — a spreadsheet, a mailbox serving as a queue, a notebook — the moments of decision and the moments of waiting. The difficulty lies in the gap between prescribed work and real work: the written procedure, where one exists, describes the nominal case, whereas time is consumed by the exceptions. That is why following one real file from end to end teaches more than an interview about how things generally work, where everyone describes in good faith what the process ought to be.
Friction points fall into a small number of families, and naming them is what allows the right remedy to be chosen. Retyping appears when the same information is written in several places by different people: it costs time, but above all it manufactures divergence. Waiting means a file that fails to progress for lack of an available person, not for lack of work to do. Searching covers the time spent finding a piece of information rather than using it. Rework means correcting downstream an error introduced upstream. A redundant check, finally, is a verification that exists because the previous one is not trusted. Each calls for a distinct answer: retyping calls for a single point of entry or a link between tools, waiting for a delegation rule, searching for a filing and naming convention. None of those three answers is necessarily a purchase.
Then comes the question of shared data. For each type of information, an organisation needs a place that carries authority: the client list, the current price list, the status of a file. When two tools each hold their own version of the same list, one of them is wrong and nobody knows which; teams end up trusting whichever they prefer, which makes the discrepancies invisible. Asking which place is authoritative, in what format the information is held and who is responsible for keeping it current is preliminary work, without which any technical link will simply propagate the errors faster. This is also the moment to examine interoperability: does a tool let its data out in a usable format, can it connect to what is already in place, or does it impose a manual export that someone will have to redo forever.
The human dimension is treated with the same seriousness as the technical one, and it is treated badly by communication alone. Reluctance is rarely irrational: someone who has built effective workarounds around a mediocre tool is defending a system that works, and is being asked to become a beginner again at a task they had mastered. Three things achieve more than any announcement. Involving the people concerned in describing the process, because correcting it makes them authors of what follows. Saying explicitly what does not change, failing which everyone imagines the worst. And answering plainly the question of the time freed up, which is asked silently from the first meeting onwards and poisons the project as long as it goes unanswered.
One criterion is always regretted when it has not been examined early enough: reversibility. Every decision carries an exit cost, and it is better to know it before committing than after. Dependency arises through three main routes: data locked in a format only the vendor can read, a configuration that exists solely in one person’s head, and a process rebuilt around a product’s quirks to the point where it can no longer be detached from it. The questions to ask before signing are therefore mundane, and they come well before any demonstration: how do we get our data back and in what form, who administers the tool from day to day, what becomes of the process if the company decides to change it.
How a support assignment unfolds
In short: Observe before proposing, rank instead of treating everything, simplify before tooling, deploy on a restricted scope, then support the teams until the old way of working has genuinely been stopped.
The first phase is observation, not a proposal. You talk to the people who carry out the work rather than to those who describe it, you follow real files, you collect the supports actually in use — including the unofficial spreadsheet that holds the whole edifice together and that nobody mentions in meetings. You also take stock of what is already in place and already paid for, because dormant features are common. This phase produces a document: a written description of the processes concerned, handed back to the teams for correction. That review is not a formality, it is where the forgotten exceptions surface, and it is also the first moment when the people involved see that the work is being done with them.
Then comes ranking, which mostly consists in giving things up. An organisation that decides to tackle everything at once tackles nothing: teams can only absorb a limited number of simultaneous changes before quality drops. The selection criteria are the frequency of the step concerned, the discomfort genuinely felt by those who put up with it, dependencies — some steps must be fixed before others that rest on them — reversibility, and how observable the result will be. The loudest irritant is not always the first to treat: a modest, visible and low-risk first undertaking builds the credit needed to tackle the subjects that touch on roles afterwards.
Simplification comes before tooling, and that order is not negotiable. You remove the steps that survived only out of habit, you merge the forms that ask for the same thing, you write down the approval rules that had stayed implicit, you decide on a single place for each type of information. The process, once lightened, becomes the specification. Set against the available tools, it makes the right questions possible: can this product do what we do, and at what price in contortions? Software always imposes a way of working; the choice consists in knowing which of its constraints you accept knowingly, rather than discovering them after deployment. The least spectacular answer — keeping the tool in place and changing how it is used — often remains defensible.
Deployment happens on a real but restricted scope: one team, one type of file, one step. You define in advance what will count as confirmation, what will count as a warning, and on what condition you go back — deciding that in advance avoids deciding it under pressure. A period in which the old and the new ways coexist is sometimes necessary, provided it is deliberate and bounded by a written exit condition rather than merely endured. During that phase, you document the process as it stabilises rather than afterwards, when nobody remembers the reasons behind a choice.
Support for the teams continues after go-live, the period where the essentials are settled. Training addresses the real cases of the trade rather than the software menus, starting with the uncomfortable situations: what do we do when a case fits none of the planned categories, whom do we ask, how do we report that something is wrong. A named internal referent is worth more than an anonymous address, and the team has to be revisited once the novelty has worn off, because that is when workarounds reappear. An undertaking ends on three conditions: the new procedure is written and available, the old one is explicitly withdrawn, and someone is appointed to maintain it. As long as both ways of working coexist without a decision, the data quietly splits in two.
The ways to get digital change wrong
In short: Tooling before the process is understood, reducing training to a demonstration on go-live day, stacking software that does not talk to itself, deciding without the people who do the work, and never stopping the old method.
The first mistake is choosing the tool before describing the process. It produces two outcomes, both costly. Either the work is distorted to fit the assumptions of the software, without anyone having chosen that reorganisation: it imposes itself by default, and is discovered by being endured. Or the product is adapted through bespoke development until it faithfully reproduces the previous disorder, at a higher cost and with dependency thrown in. The most reliable sign that this mistake has been made appears some time after go-live: parallel spreadsheets reappear. They mean the tool does not cover a real case and that the team has quietly repaired the gap without saying so, because the project was officially a success.
The second is reducing training to a demonstration at go-live. A demonstration shows the screens in a comfortable order, to people who have no urgent file waiting. What a team needs is different: seeing its own cases handled, especially the awkward ones, and knowing what to do when the tool cannot do something. The other variant of the same problem consists in training one referent and leaving them to train everyone else. Knowledge then concentrates in a single head; the day that person is away or leaves the company, the process goes with them. Writing the procedure down and having several people practise it costs little and prevents exactly that.
The third is stacking tools that do not communicate. Each need finds its answer separately, each product is good in isolation, and nobody decides on the whole. People then become the interface between the pieces of software: they copy from one screen to another, they arbitrate between two contradictory versions of the same data, they know which one is current because they remember. The cost of the subscriptions shows on an invoice; the cost of that coordination shows nowhere and grows with every addition. Before introducing one more tool, two questions are worth asking: what does it replace, and how does it connect to what remains? A tool that adds a place to look without removing another adds work.
The fourth concerns the way the decision is taken and announced. A change designed far from those who do the work rests on a false description of the process, and it is received as a suspicion of inefficiency — which is enough to produce a polite and lasting refusal. Four points deserve to be put explicitly before the first deployment: the problem being solved and how everyone will know it has been, the scope affected at this stage and the scope not yet affected, the way difficulties are meant to be raised and to whom, and the person who settles matters when two departments disagree. To which is added a scheduling choice that is too often neglected: launching a change during the busiest stretch of the business guarantees that nobody will have the mental room to learn it, and turns a normal difficulty into a failure blamed on the tool.
The fifth is never stopping the old method, and having recorded the initial state nowhere. As long as both systems coexist without a decision, information distributes itself between them according to individual preference and neither is complete; the organisation ends up less reliable than before it started. As for the initial state, if it was never described — how many places had to be consulted to answer a routine question, which steps forced someone to ask again for information already supplied, what the teams complained about unprompted — the discussion about results will come down to contradictory impressions. Those two omissions meet in a third: the undertaking with no defined end, which drifts into permanent configuration that nobody dares interrupt.
When digital transformation support is not the right answer
In short: An organisation in crisis must stabilise first; a very small team often gains more from removing steps than from adding a tool; and no amount of internal fluidity makes up for an offer nobody buys.
The first case is the organisation in crisis. Strained cash, an unresolved internal conflict, an imminent regulatory deadline, the departure of the person who single-handedly held up part of the business: these situations demand exactly what a change consumes, namely attention, availability and tolerance for a temporary drop in performance. And every change degrades before it improves, because acquired reflexes stop being useful during the learning period. Launching a transformation at such a moment amounts to asking for extra effort from a team already overdrawn. The honest sequence is the reverse: stabilise first, including through crude and provisional measures, then transform once the organisation has room to manoeuvre again.
The second case is the very small team. A good share of the value of a management tool lies in coordination: it lets people who do not talk to each other share a common picture. In a team where everyone knows what the others are doing, that benefit is slight, while the costs remain whole — a subscription, an administration to keep up, one more thing to maintain, one more place to look. The gain then lies elsewhere: removing steps, reducing the number of places where information is written, stopping the production of a report nobody reads, merging two files into one. Such changes do not sell well, they do not display on a home page, and they often deliver more. Tooling becomes relevant later, when headcount grows or when someone has to be replaceable.
The third case is the one where the problem is not in the process. Digital change makes an organisation more efficient at what it already does; it says nothing about whether what it does is worth doing. If the product does not meet its market, if the margin is structurally insufficient, if clients leave for a reason that lies in the offer, improving how information circulates internally only accelerates the march towards the same wall. The diagnosis must therefore distinguish a company slowed down by its processes from a company in commercial difficulty attributing to its tools a cause that lies elsewhere. The confusion is frequent and understandable, because a process is a repairable object, whereas the other question is painful.
The fourth case concerns the availability of decision-making. An undertaking of this kind raises trade-offs that no supplier can settle in the company’s place: who approves from now on, which exception stops being handled, which rule becomes binding. If nobody has the mandate to decide, or if those who have it cannot free the time required, the work stops at the diagnosis stage and produces a document nobody will apply. The same holds for saturated teams: the availability to learn is a resource just as budget is, and it has to be reserved before starting. Better to postpone than to produce one more report.
The fifth case is a question of timing. A change is justified by a trigger: growth that makes informal coordination impractical, the foreseeable departure of the person holding unwritten knowledge, a new obligation, a volume that no longer gets through. In the absence of a trigger, an organisation that works can legitimately decide to carry on as it is, and that is not falling behind. The useful question is therefore not whether a company is ahead or behind, but whether something hampers it enough to justify the effort. When the answer is no, saying so is part of the work, and agreeing to look again once the situation has changed is better than an undertaking launched for the sake of not standing still.
Frequently asked questions
Does digital change necessarily mean new software?
No, and the opposite is often what happens. A large share of the gains comes from removing steps that had become pointless, from deciding on a single place for each type of information, or from switching on features already included in a tool you have and never used. Software becomes necessary when the simplified process exceeds what the existing tools can carry — not before. Starting with the purchase means answering a question that has not yet been asked.
Where do you start when everything seems to need reworking?
With one thing, chosen for good reasons. You first describe the most frequent process, the one that touches the most files, because that is where friction repeats itself. You then choose a first undertaking that is modest, visible and reversible, and about which you will be able to say whether it worked. Tackling everything at once guarantees the opposite of the result sought: the available attention scatters, no undertaking goes far enough to produce a visible effect, and the organisation concludes that nothing works. One undertaking carried through to the end makes the next markedly easier to get accepted.
Do you need an internal referent, and what exactly do they do?
Yes, and the role is broader than it looks. The referent is not the software specialist but the team’s point of contact: they collect the irritants, tell apart what stems from a lack of training and what stems from a design flaw, and pass on the cases that were not anticipated. They must be available, known to everyone and recognised by management. What they must not be is the only person who knows: the knowledge has to be written down and practised by several people, otherwise their absence blocks the process.
What do you do when part of the team is against it?
You listen to the objection before answering it, because it is often accurate. Opposition frequently signals a real case the new process does not cover, or an extra workload nobody saw. Three levers work: involving the people concerned in describing the process, saying explicitly what does not change, and showing a benefit for the person themselves and not only for the organisation. What does not work is treating refusal as a communication problem to be fixed with one more meeting.
What happens to existing spreadsheets and files?
They deserve examination rather than abandonment. A spreadsheet that holds a business together contains rules that have never been written down anywhere else: it is a valuable source of documentation. Migrating the data then raises three distinct questions: what is carried over, what is archived without being carried over, and what is dropped because it no longer serves any purpose. Carrying over an entire questionable history imports the errors into the new tool and loses trust from the very first use.
Is one single tool better than several specialised ones?
It depends on how much information has to travel between the steps. A single tool simplifies data consistency and administration, at the price of average features everywhere. Specialised tools each do better in their own field, but the cost shifts to the links between them and to the people who maintain those links. The deciding criterion is therefore real interoperability, not functional richness: an excellent product that will not let its data out ends up constraining the whole rest of the organisation.
How do you avoid ending up locked in by a vendor?
By treating the exit as a selection criterion rather than as an unpleasant hypothesis. Three checks before committing: can the data be exported in a format readable without the tool, is the configuration documented somewhere other than in one person’s memory, and does the process stay understandable independently of the product. You also need to check who administers the tool day to day: when that skill is entirely outsourced, the dependency is on the supplier as much as on the software.
How can you tell that a change has actually helped?
By observable signs, chosen and recorded before starting. Depending on the case: the number of places to consult in order to answer a routine question, the number of times the same information is captured, the gap between a request arriving and someone actually taking it on, the ability to answer a client without consulting a colleague, the ease with which one person picks up a file started by someone else. You also watch how the new process is really used: the reappearance of parallel files is the most reliable signal that a case is not covered.
How do you know when an undertaking is finished?
An undertaking is not finished when the tool is installed, but when three conditions are met: the new procedure is written and available, the old one is explicitly withdrawn rather than left running in parallel, and a person is appointed to maintain the whole. Without that stopping point, the project stretches into indefinite adjustment and the organisation gets used to living on a building site. Transforming an organisation is not a continuous state: it is a succession of undertakings that begin and that end.
Can this work be done in-house, without an outside view?
Yes, and many organisations do it. An outside view brings two things that are hard to obtain internally: it asks the naive questions nobody dares ask any more, and it has no stake in the trade-offs between departments. What it does not hold is knowledge of the trade, which stays with those who practise it. Support that claimed to decide in the team’s place would produce a theoretical description of the work — which is precisely the document nobody applies.