Innovating in an SME without wasting budget: the first steps that matter

The first step isn't choosing a technology, it's understanding where you're losing value today. Before talking about software, AI or automation, you need a diagnosis: which processes cost you the most time, generate the most errors, or slow down the customer. From there a list of concrete problems emerges, ranked by impact.

Only after mapping where the value sits does it make sense to decide what to do and with which tool. Starting from the tool ("I need a CRM", "I need AI") is the most common way to spend well on a problem that wasn't actually your main problem. Innovating means fixing the right bottleneck, not adopting the trendiest technology.

GiBSeS — GiBSeS's Value Map method starts right here: diagnosis first, decision second.

The best candidates share three traits at once: they're repetitive, they're frequent, and they follow reasonably stable rules. A task you do a hundred times a month, always following the same steps, pays off far more than a rare process full of exceptions.

A practical approach is to plot each process on two axes: how much it weighs (time, cost, errors) and how easy it is to automate. Start with what sits in the top right: high impact, low difficulty. Avoid the trap of automating the most fascinating or most visible process — it's often not the one that saves you the most.

GiBSeS — This impact-and-feasibility mapping is at the heart of the initial diagnosis we run with SMEs.

An initial diagnosis is a reasoned snapshot of how you work today: the key processes, where time or money is being lost, what data you have and what state it's in, and what the real constraints are (people, budget, skills). It's not an endless audit: for an SME, a few weeks are normally enough, not months.

What it should leave you with is a list of prioritized initiatives, each with an estimate of impact and effort, and an initial indication of what's worth buying and what might be worth building. If an analysis ends with nothing more than a generic presentation and no operational decision, it hasn't done its job.

GiBSeS — We always deliver a decidable map: priorities, expected effort and a make-or-buy direction — not slides.

A PoC is a small, tightly scoped experiment to check whether an idea actually works before investing in it seriously. It's meant to answer one precise question ("does this approach hold up on our real data?") with limited risk and cost — not to build the final system.

It's worth doing when there's genuine technical or value uncertainty: new technology, questionable data, a process never automated before. Define upfront what you'll consider a success and a maximum timeframe (often a few weeks). If there's no real uncertainty, a PoC is just a way of postponing the decision: better to start with an actual quick win.

GiBSeS — We use PoCs only when they reduce a concrete risk, with success criteria set before we start.

The pragmatic rule is: buy what's standard, build only what truly sets you apart. Invoicing, accounting, email, document management are problems already solved very well by off-the-shelf products: building them in-house is almost always a waste. Custom development only makes sense where the process is a genuinely unique competitive advantage and no ready-made solution covers it.

Remember that the cost of in-house software isn't the initial development — it's the maintenance for years afterward: updates, security, the one person who knows the system and who will one day leave. Always evaluate total cost over time, not the price tag on day one.

GiBSeS — The make-or-buy decision, evaluated on total cost rather than the initial quote, is a central part of our method.

Vendor lock-in is the situation where switching providers becomes so costly or difficult that you're effectively forced to stay, even when the service gets worse or prices go up. To protect yourself, before signing ask three things: can I export my data in an open, complete format? Does the system integrate with others through standards? What happens if I want to leave tomorrow?

Be wary of solutions that make it very easy to get in and very hard to get out. Favor open formats, contracts with clear exit clauses, and full ownership of your data. Independence isn't ideology — it's negotiating power that stays with you over time.

GiBSeS — GiBSeS is an advisor independent from vendors precisely to protect this: your freedom to change your mind.

Whoever sells a technology has a legitimate but one-sided interest: selling their own technology. A software house will propose software, an AI company will propose AI, and they'll do so even when your problem would be better solved with a shared spreadsheet or a process change. It's not bad faith — it's their business model.

An independent advisor doesn't profit from the solution you choose, so they can also tell you "you don't need technology here" or "this cheaper product is simply enough". Their incentive is aligned with your outcome, not with selling a license.

GiBSeS — GiBSeS's incentive is your outcome: we don't sell our own technology, so we can also tell you not to buy it.

AI is a powerful tool for a few specific problems: understanding and generating text, classifying large volumes, finding patterns across lots of data, handling requests in natural language. For a great many SME problems, though, the right solution is still traditional automation, better-organized data, or simply a clearer process — no AI involved.

The right question isn't "how do I use AI?" but "what's my problem, and what's the simplest tool that solves it?". Sometimes that tool is AI, often it isn't. Adopting it just because everyone's talking about it is the fastest way to spend a lot and use it very little.

GiBSeS — We evaluate AI as one tool among others, and only propose it when the risk-benefit analysis justifies it.

No, and waiting for "perfect" data is a great way to never start. The data quality you need depends on the project: some automations work perfectly well even with imperfect data, others (especially AI-based ones) are more sensitive. What matters is understanding which data is critical for that specific goal and fixing only that.

Often the first project itself helps you discover and improve the data that actually matters. Better to start from a concrete case and clean up the minimum necessary, rather than launch an endless "data cleanup" project that eats up budget without ever producing a visible result.

GiBSeS — In the diagnosis we identify which data is truly critical for the goal, so you don't clean up more than necessary.

It depends on the ambition, but the right principle is to aim for a first visible result within weeks, not years. A well-chosen quick win (an automation that removes a repetitive manual task, for instance) can pay off almost immediately and fund — in credibility, and sometimes in cash — the steps that follow.

More structural projects take longer, and that's normal. But if your first initiative produces nothing tangible for many months, you picked the wrong starting point. A sequence of small, measurable wins beats one big project that promises everything and only shows results "at the end".

GiBSeS — We prefer to start with a fast, measurable quick win, then build the structure on the results it delivers.

Projects that end up shelved almost always have two causes: they started from a technology instead of a felt problem, and they didn't involve the people who would actually have to use them. To avoid this, tie every project to a problem people recognize as their own, define upfront how you'll measure success, and involve end users from the diagnosis stage onward.

A second antidote is to proceed in small, reversible steps. If you invest everything in one big system before verifying that it works and will actually be adopted, the risk is high. If you start with small, measurable initiatives, every subsequent euro is spent knowing the previous one paid off.

GiBSeS — Diagnosis first, then measurable quick wins, then structure: that's how we reduce the risk of a project going unused.

You need three roles, even in a small company. A sponsor with the authority to decide and unlock budget and priorities (often the owner). The people who do the work every day, because they know the real exceptions that no procedure ever writes down. And someone who keeps hold of the thread of the project, an internal point of contact who tracks progress.

Involving the people who operate the process isn't a courtesy — it's the difference between a tool that gets adopted and one that gets rejected. If solutions are imposed from above without listening to the people who'll use them, adoption collapses, no matter how good the technology is.

GiBSeS — We work alongside the sponsor and the operating staff from the very first diagnosis, not only at delivery.

Define the measure before you start, not after. Choose one or two metrics tied to the original problem: hours saved per week, customer response time, number of errors, days to close a case. Record the starting value (the baseline) before the intervention, otherwise you won't be able to tell whether it improved.

Be wary of vanity metrics like "number of features" or "registered users": measure the effect on the business, not the activity. If you can't define upfront how you'll know it worked, the project's goal is probably not yet clear enough to start.

GiBSeS — Setting the baseline and outcome metrics before starting is part of how we set up every engagement.

No. The most expensive mistake isn't spending too little — it's spending a lot on the wrong thing. A serious diagnosis and a first quick win require a modest investment relative to the value they unlock, and their whole point is to stop you committing significant sums before you know where it's worth putting them.

Think in terms of order of magnitude and steps: a small first initiative, then you scale up on what paid off. Many useful automations rely on tools you already own or on affordable subscription solutions. In an SME, the scarcest resource is usually not money — it's attention: don't spread it thin across too many fronts at once.

GiBSeS — We start with initiatives sized to the SME's reality, so the investment follows the results instead of preceding them.

A good consultant starts from your questions and your processes, not from their catalog. They get you talking about the problem before naming a solution, are willing to tell you a project isn't needed, and are transparent about their own incentives (who pays them and how). They leave you owning your data and your choices — they don't tie you down.

Warning signs: promises of guaranteed results, one solution that's supposedly good for everything, plenty of acronyms and few questions about your actual work, and pressure to decide quickly. Real expertise shows in how many good questions someone asks before proposing anything, not in how fast they propose it.

GiBSeS — Independence, transparency about incentives, and your ownership of your data are the principles GiBSeS works by.

It's an ongoing journey, not a single big project with an end date. The market, the tools, and your company all change: a solution that's perfect today will need revisiting tomorrow. The healthier approach is continuous improvement, made up of short cycles: spot a problem, make a small intervention, measure, learn, move on to the next one.

This also protects you from the "big leap" risk: instead of betting everything on a multi-year project that could be outdated before it's even finished, you build a steady capacity to improve one piece at a time. Discipline, not heroics, is what grows an SME over time.

GiBSeS — Continuous improvement and small, reversible steps are at the core of how we support SMEs over time.

Traditional automation executes precise rules that you define: "when an invoice arrives, save it here and notify this person". It's predictable, reliable, and transparent — it does exactly what you tell it to. It covers a huge share of an SME's real needs, often with no AI required.

AI is needed when the rules can't all be written in advance, because the input is ambiguous or in natural language: interpreting a text, summarizing documents, answering varied questions. It's more flexible but also less predictable, and needs to be kept in check. Knowing when plain automation is enough and when AI is genuinely needed saves you from paying for complexity you don't need.

GiBSeS — Telling apart when simple automation is enough and when AI is actually needed is exactly the kind of decision we help make.

Choose the project that sits at the intersection of high daily friction and low implementation complexity: a problem everyone in the company recognizes, that recurs often, and that can be solved without overhauling everything. A good first project is important enough to be noticed when it works, but small enough to wrap up quickly.

Avoid the most ambitious or most "strategic" project as a first step: it has more unknowns and takes longer, and if it goes wrong it burns trust as well as budget. The first project also builds internal credibility and teaches you how you and your provider work together. Win a small battle before launching the big campaign.

GiBSeS — We help identify that first high-impact, low-risk initiative — the quick win everything else builds on.