Who asked you to change ERP partners?

By Peter Nicholson

There's one piece of ERP work you keep putting off. You trust your partner. You like them. But this particular job needs experience they don't have, so it sits on the list year after year, because the only alternative seems to be changing partners, and nobody wants that fight.

This week we were joined by Ken Sebahar, who began implementing Navision back in 2001, spent 23 years working his way from application consultant to CEO at a Microsoft partner in the Chicago area, and now advises companies independently on getting more out of Business Central. He also co-hosted A Shot of Business Central and a Beer, and I listened to every single episode, so I'll admit to being slightly starstruck. I had a pale bitter from a tiny Lake District brewery on the desk in its honour. It was 3:39 in the afternoon. Socially acceptable.

We were there to talk about his white paper, The Multi-Partner Advantage, and I found myself nodding along to most of it.

Who asked you to change partners?

Ken wrote it because of a conversation he kept having. He'd be talking to a business running Business Central with an obvious gap, a pain point he or someone he knew could fix, and the first reply was nearly always the same: we're happy with our partner, we're not interested in changing. And in his head: who asked you to change partners?

His diagnosis is that most businesses assume they need a partner, singular, and that anything touching the ERP, directly or tangentially, has to go through them. Bring in someone else, a smaller firm or an independent consultant, and there'll be hurt feelings. So they don't. Not because they've weighed it up, but because they've never thought about it. They don't have a partner strategy. They have a partner.

That used to be fine. In the Navision days the database was proprietary and locked down, and, as Ken put it, a consultant and a developer with full access to the source code could accomplish pretty much anything. That world has expanded exponentially. Everything now wants to connect to everything else, and it's getting harder to find one partner who's genuinely expert in all of it. So Ken reframes the question. It isn't "which partner?" but "how do I make the best use of the partner network?" Sometimes the answer is still one partner. Sometimes it isn't.

Write down what you expect

Whether you end up with one partner or several, Ken's first step is the same, and it isn't complicated: write down what you expect from your partner, and share it with them.

That means saying where you're strong and where you aren't. We've got a solid finance team, we understand our chart of accounts and dimensions, but manufacturing is a struggle, so beyond implementing it we'll need you to guide us on how to set up routings. It means listing the areas you'll lean on them for: Business Central, but perhaps Power BI too, or supporting an e-commerce integration. It means response times. And it means accepting that a ten-user business and a three-hundred-user business rely on a partner in completely different ways.

The reason it matters is everything that goes unsaid. Ken's example is painfully familiar. Three or four months after go-live, a customer looks at the balance sheet, finds none of the inventory accounts reconcile, and rings the partner. The partner points out they haven't been closing their inventory periods or updating posting dates. The customer's reply, "we thought you were doing that, we're on the support contract", is the whole problem in one sentence. Nobody wrote it down.

Do the exercise properly and the gaps tend to reveal themselves. That's where a second partner starts to make sense.

Listen for the gaps in the answer

Emily, who is very good at taking a vendor apart, spotted the implication straight away: if you're not relying on one partner for everything, they don't need to tick every box. Pick one who's excellent at the backbone, finance and manufacturing, and look elsewhere for, say, the customer relationship side.

Ken's EDI example is the one I'd pin to the wall. You tell your partner you need EDI and they recommend a solution. Why that one? Possibly because it's the best. Possibly because it's the one they know. Or they've an EDI person on staff who has done it before but isn't really an expert, and you can hear it: gaps in the answers, confidence that isn't quite there. What most people do next is march forward anyway, because this is their partner and this is what their partner says. Ken's advice is simply: don't. Look at the whole range of options and go into the project as confident as you can be, because on a big project there's plenty that can go south.

Emily's follow-up was fair. Surely a good partner facilitates that anyway and brings in a specialist behind the scenes? Sometimes, and that can work. But a partner's instinct is to take the business on and solve it themselves. The difference Ken is describing is that you, the customer, feel able to say it out loud.

How to tell your partner

This is the bit that makes people nervous, and rightly so. Ken put it to Nirav directly: you've been doing a great job supporting me, but I'm going to talk to a couple of other partners about this project. First reaction? What did I do wrong? Nirav didn't hesitate. That is definitely the first reaction.

So it comes down to tone. Ken's version goes something like: I love our relationship, you've been doing a great job helping us run Business Central. This CRM project is really important and it has to go well. I'll need you to be part of it, I don't yet know to what degree, but I'm also going to talk to some CRM experts, and we'll all be on the same team. That asks something of both sides. The customer has to accept their partner won't have every answer. The partner has to accept that bringing in someone else for, say, reporting and data analytics doesn't mean something has gone wrong.

Emily added the risk from the customer's side, and it's a real one. With smaller partners especially, a lot runs on near-handshake agreements: we haven't signed yet, but we'll definitely need you in November, so please hold that time for us. That kind of trust is one of the best things about working with smaller firms. Give them the impression you've one foot out of the door and you can hardly blame them for prioritising other customers. How to break the news was, she said, written in her notes before we started.

Ken's other point is that adding a partner doesn't need the giant evaluation people associate with switching. Sometimes the relationship is broken and you do have to change your primary partner. Often it isn't. You can keep getting value from the partner you have and bring someone in to supplement support, run some user training or help with Power BI. His observation from years on the partner side: even at a company the size of Microsoft, there's often exactly one person who can answer your specific question. The same is true at a partner of a thousand people or twenty-five. And there are plenty of one-to-ten-person firms now with very deep expertise. Of course you should use them.

Who do I call on a Friday afternoon?

My own worry going in was the jigsaw. Say your partner is great at finance. Nice people, always answer the phone to your stupid questions. But you want a barcoded warehouse, and they're stumbling through WMS, so you bring in a WMS specialist. Now instead of one piece that was the whole picture, you've got a puzzle where every piece is a different partner to manage. Then an update goes through on a Friday afternoon, pick lists are generated in the system, and the warehouse can't see them. Who do you ring?

Ken's answer was calmer than I expected. You still have a primary support partner, and the ticket goes to them. If they find the issue sits with Tasklet Factory or Insight Works, they circle that team in. That already happens today, since partners use ISV teams to handle support cases all the time. You just don't see it. A multi-partner setup makes it open rather than hidden. You already deal with different people inside your partner for the general ledger, inventory and projects; this extends the team. Draw clear lines (CRM integration goes to this person, Power BI goes over there) and make sure everyone is a willing player. If someone is hostile to the arrangement, that's the thing to deal with.

Nirav, speaking from the partner side, liked the model and gave it the best analogy of the episode. You don't ask your family doctor for a quadruple bypass; you see a cardiologist. But the GP works out the symptoms first, decides whether it's something they can handle or needs a specialist, and hands over what they know. You can't just drop a WMS specialist in without them knowing how your items are set up, how locations and bins are defined, and what's been customised around the warehouse. The general partner's knowledge is the bridge. He also asked the question every partner will be thinking: who finds the specialist? Leave customers to download whatever they fancy and they can make a real mess of the database. His view is that the partner who did the bulk of the implementation should at least be in the conversation, and he floated a sandbox-first rule before anything touches production.

Whose system is it?

That led us into AppSource, where every app has a lovely shop window, a video and a free trial. The risk I raised is the business that trials something shiny for a feature Business Central already has. They just never switched it on. Who's meant to catch that?

Ken's ideal is someone like Emily inside the business, with the experience to evaluate the options, whether that's a full WMS or something as small as an integrated credit card app. The customer should own it, because the best Business Central users he's seen are the ones who say "this is our system, and we're responsible for its success". The warning sign is someone telling their partner "your system". It sounded exactly like my mum when something goes wrong with her phone. Nirav opens every new project by saying it outright: if this is your first ERP, it'll be the hardest thing you do as a business, and this is your system, not mine.

The reality in the small and mid-market, as Ken says, is that most businesses don't have an Emily. It's the controller or the sales manager asking the partner to find a credit card app. By Ken's account, Microsoft has also been pushing partners to build curated lists of apps they'll sell, implement and support, which is understandable with somewhere around three thousand Business Central apps out there. When he was working at a partner they were deliberately app-agnostic: here are six viable candidates, here are the two or three we'd look at first. Today a partner might just tell you what to use. Is that the best fit for your requirements, or the one they've done most and are most comfortable with? And if you choose option four, one your partner has never implemented, the app developer becomes another partner. Ideally one you can call directly, rather than your partner forwarding the ticket on.

Verticalise, then acquire

Nirav asked whether this works better with a boutique general partner or a big one with a larger address book. Ken's answer: there's no one-size-fits-all. Two businesses of the same size, in the same industry and the same region, can have completely different personalities and expectations.

He did give the classic case, though. Microsoft has spent years pushing partners to verticalise. So a partner does, becomes the manufacturing expert, and sells you on exactly that. Two years later you acquire a business that does project-based work, with revenue recognition, WIP and everything that comes with it. You shouldn't expect your manufacturing partner to suddenly be expert in project accounting. What too often happens is the customer asks "can you help us with this?", and the question becomes whether the partner has the wherewithal to say: not our wheelhouse, we want to be part of it, but we shouldn't lead it.

Nirav's view was that it's entirely fine to have that conversation now, and to treat it like finding a specialist doctor. Interview two or three: a couple your partner recommends, a couple you find yourself. When it's your money, your users and your time on the line, measure twice and cut once.

The partner who'll tell you no

Emily made the point I'd most want a finance director to hear. Plenty of partners can build what you ask for. Describe your process and they'll get it in somehow, usually with some customisation. That isn't what she's paying for when she goes looking for deep expertise. She wants a partner who understands what she's trying to achieve and knows the business and the system well enough to say: we don't think you should do it exactly the way you've described. Here's how other companies do it, with out-of-the-box configuration. That's the version that survives upgrades, needs less testing, and doesn't cost you again every time a customisation has to be reworked.

Ken framed the same thing as a second opinion. Your second partner may never touch Business Central at all. They might just be an adviser you can ask: here's what we're planning, does it make sense, have you seen others do it? That alone can stop you going down a rabbit hole you really don't want to go down.

Nirav pointed to the illustration on page 17 of Ken's paper, the Microsoft ecosystem surrounding Business Central, and argued it's next to impossible for one partner to know all of it. Teams, Outlook, Power Automate flows, and those were just the ones off the top of his head. Stick with one partner for everything and you may be limiting what the business can do.

My contribution is that the world changed underneath us. A small manufacturer used to be just that. Now the same business sells through its own website and on Amazon, ships through a third-party logistics provider, and plugs in low-code connectors built by companies who desperately want you to buy them. So I'd be very dubious of any ERP partner who's expert in that, and that, and that as well. Really? All of it?

When one partner is plenty

To Ken's credit, he isn't selling this to everyone. His counter-example is a business on Business Central running general ledger, payables and receivables, with invoices fed in from a third-party billing system, one or two apps the partner supports well, and an in-house data analyst using the Microsoft tools for a data warehouse and reporting. They ring the partner a couple of times a month. Why would they bring anyone else in?

His point isn't "have multiple partners". It's "make a conscious decision about how many partners you have". The need comes first.

If you want to go further, Ken's site, speakingbusinesscentral.com, has the paper and a Business Central terminology guide I'm a big fan of. It started life as a book, until he asked his daughter, then at college, what she'd pay for it. Zero. Her suggestion, a website he could keep updated, is why it exists. He also puts out a monthly update video: fifteen minutes, or ten at one-and-a-half speed.

Nirav, for his part, plays the GP for Acumatica customers at AdCirrus. He still hasn't paid me to say that.

Listen to the full conversation: Ken Sebahar on The ABCs of ERP & Beyond, with Peter Nicholson, Nirav Shah and Emily Browning.