Any time ERP is being discussed, Excel is a sore point. Excel is a niggle, an elephant in the room or an outright argument in the context of all sorts of systems, actually, in reporting, management, whatever.

What I notice is that there are often strong entrenched views in which neither side, pro-Excel or anti-Excel really understand each other. It’s a fight over something else that neither side quite acknowledge.

The core fact is that Excel is an extraordinary tool. It can do so much, in such a variety of ways, that it’s almost no exaggeration to say that at least in business terms it can almost do everything.

I was using Excel long before I got involved with ERP, and got deep into the VBA side, the code scripts below the surface of what most users see, so I know what it can do. I have made full standalone applications within Excel. And they stayed the way of doing those things for years in the places I worked.

So, if it's great, what's the problem?

The perfect use for a spreadsheet has at least one of two key factors, preferably both:

1. It's for and by a single person.
2. When you're done, you're done.

Given those, Excel is great. Analysis, preparation of data, calculation. For you, or to pass on to someone who needs it. There's little better.

Collaboration, as most people find out, is less ideal. Google Sheets and Excel online can be used collaboratively, but there's an art to doing so successfully, and a lot of that art is in knowing the limitations and when it's worth doing at all.

Similarly, a spreadsheet that tells us something is brilliant, but one that has become an entire history starts to be a drag in various ways. A constantly-updated spreadsheet, or one with versions dating back to Dave who set it up in 2014, is the little piece of wood under the table that otherwise wobbles. It's not doing anything wrong in itself, but it's a sign of something that hasn't been fixed.

Horses for courses

When techy types complain that "Excel is not a database", they aren't saying you can't use Excel for data.

Databases, which are what ERP systems are built on, are optimised for scale and concurrency. What that means, in plain English, is that as more people use them more, and all at the same time, they keep working and stay consistent. So ERPs are the same, and if someone in the Finance department calls up the figures that the factory floor is working on, right now, both can rely on those numbers and not be held up. Spreadsheets aren't like that, and aren't intended to be, because they are optimised for flexibility.

And that's the trade-off of teamwork in general, isn't it? If you want to do what you like, work alone and let your genius flow freely. When you work with others, you gain all their capability as well as your own, but need some basic agreed rules so you're not all pulling in different directions.

Which points to the real main reason those with a broader view – managers, consultants etc – tend to worry when spreadsheets become a critical part of how things are done. It might be completely fine, but too often it's a sign of individual workarounds in situations where standardisation and sharing would be better.

But how can we tell?

My rule of thumb is: if you need to know something, and you don't make changes to the ERP system as a result of your Excel work, you're fine. Export from the ERP and do what you need. If you're doing it regularly in the same way, you might want to think about alternatives to make whatever-it-is more efficient, but no harm is being done.

If you pass the file around, or others are dependent on it or what you tell them from it, or data is fed back into the ERP, you have a problem even if you don't realise it. And you might not be uploading the data, necessarily, but adjusting things by hand based on your spreadsheet, which is as bad.

In those cases, the system that's running the business is blind to exactly those things, which means that people can't know what they need to, in ways that may not be clear to you.

The table isn't wobbling right now, maybe, but ... someone is resting something vital on outdated data, things only work because one particular person has a way of doing it that only they know, and maybe hours a week are going into something that should be happening automatically.

So what can we do?

Well, you can call META eight, for one option.

What action you take (or we take for you) depends on what the underlying reason for the spreadsheet-in-the-process is.

Sometimes it's a lack of trust in the ERP data. Missing data, or suspected wrong values. Or even data pulled from elsewhere, like a supplier product or price list, or a map of delivery areas, that was never added or connected.

Sometimes it's missing functionality or logic that doesn't exist in the ERP, so somebody has to do it another way.

Sometimes it's really only that it's either easier, or people don't know how to use the ERP itself for something.

So there's no one simple answer, and it usually starts with some detective clue-gathering, and unthreatening queries of people who know the realities of the actual work. The technical answers flow from that, when they're needed.

They provide information that makes the business work better. And are powered by information that goes into them.

They are successful when the information out is clearly worth the trouble of getting the information in. And that needs to be so at all levels, from the business as a whole to each individual.

When implementing a system, or making changes, there’s an understandable tendency to focus on the bigger picture. The costs are usually high, the disruption very noticeable, and the return on investment is obviously tied to getting something back at the business level. What each individual involved gets out of it, personally, confuses the bigger issue.

Sometimes, I must say, even that obvious point isn’t considered. There are many and varied reasons for investing massive time, money and trouble in a new system, and the unacknowledged ones are often a bigger part than anyone wants to think about – marking territory, forcing change of apparently unrelated kinds, demonstrating authority. Where those are the dominant factors, success is measured by other things than what the new system can do, whatever the stated measures.

Considered for themselves, though, a successful business system is one that acts as a force multiplier for the information in the business, and is seen to do so.

Being seen to provide an information benefit … that is also more subtle than it first appears. As politicians discover, everybody wants benefits, and much fewer want the cost. In business systems, as in society, there is almost always a disconnect between what we get out and the cost of it. One person’s benefit is another’s cost. Even when, as in our own tiny business, there are very few people, future me can seem like someone who can manage fine if I don’t do this annoying data entry now.

We know this, don’t we? What we don’t often do is openly consider it and plan accordingly.

The three possible strategies

Consciously or otherwise, there are three basic strategies: discipline, incentive and automation, and they can be mixed.

Discipline and control are the obvious answers. It’s natural for business leaders to assume that if something is essential, like data entry, they can just say that it must be done and it will be. Practically, this is not ideal, even where it does actually happen as planned.

Incentives are better, just as long as they’re not naive incentives. Offering, for example, bonuses for completed data entry is not a true incentive, but closer to a benign sort of discipline. Real incentives make the clear link between the necessary work and the desired outcome, and help the work to seem worthwhile. In some cases it can be enough to put workers on different stages of a process close together, so that the problems arising from poor information are very visible to those at the stage when they can do something about it.

And automation? Well, that simply reduces the problem directly. People don’t like stopping what they’re doing to enter data about it, and will get round doing it if they can. If that data entry can be automatic, even partially, it will happen anyway with no friction, and everyone benefits. Connect a scale to the computer and nobody needs to enter a weight. Input documents with OCR. Scan RFID tags as items pass rather than have humans note them. Trigger changes on actions. Make users' working lives easier, and automation is welcomed.

So, for successful processes: make the data entry as automatic as possible, make it easy where you can’t make it automatic, link effort to results … and fall back on control only as a last resort.

This is not rocket science, and provides a useful lens to consider every process in a business, not only ones within formal systems, however small or large.

The well-documented lack of success in big systems projects is, I suggest, largely down to the fact that at the top levels of a business don’t think this way when organising them.

Actual practical steps towards doing this are the next thing …

When implementing Kinetic, or any ERP, far more of the success or failure is down to how well you adapt and define your business processes than any other factor.

Why?

An ERP is many things in a business, but all of them rely on predictability and auditable data. That means defined business logic, defined flows, and knowing that it will be the same every time as well as that it can be inspected to mine what happened. For it to be able to do that, the real-world things that it models, records and controls, need to be defined, too.

They also need to be mapped cleanly and reliably to the built-in logic of the ERP itself. This is why implementation specialists tend to strongly recommend changing the company's processes to become more similar to the standard pattern of the ERP, as they can then guarantee a match and reliable functioning.

So, processes are good, then?

Processes are good, definitely. More than that, they're essential, which isn't quite the same thing.

But to anyone involved in ERP, this isn't news. What is less often mentioned is the limitations of process, and they're important. Slightly more abstract, and under-appreciated, but important.

Here's some things to consider.

The human factor

Computers and humans are good at different things. Computers are reliable. They will do exactly what they've been set up to do. If they're not doing the right thing, that's because you've set them up wrong. Humans are variable, flexible and intelligent. If they can see that pushing a button is going to cause a disaster, they won't do it. But they can also have off days when they make mistakes.

Managers and people running organisations like machines for that reason. And when you have powerful machinery and capable software, it's tempting to elevate it above the fallible humans. Get the software to control what the people do, and aim at making the humans as predictable as the machines.

The first disadvantage of this is that it's unnatural for those humans, strips them of a sense of meaning in what they do, and leads to dissatisfaction as a result.

If that's not a worry, you lose the edge that the combination of machine predictability and human judgement can bring. Too tightly defined, and the human becomes constrained by the limits of what the machine can do, while not being able to match its reliability. In attempting to eliminate mistakes, you actually remove local discretion and flexible decision-making.

Whatever you do, workarounds will develop. Either edge cases will be forced into standard patterns that don't suit them, or things will start to happen in ways that aren't approved, outside the systems you think you have. And all the time, it's pointless to have skilled and capable staff because they don't have any way to utilise the value they could bring.

In a chaotic world, predictability can be risky

Processes are designed around, and suit, the foreseeable. Every possibility needs to be allowed for.

In practical reality, it's not even possible to imagine every possibility. And if it was possible, in the case of ERP it would lead to such complexity that it would be a functional and maintenance nightmare. So in the real world, we build around a relatively fixed array of known eventualities, and we organise the framework we work within so as to limit what can happen. We assume a certain stability.

There are times, for all sorts of reasons, when everything becomes far less stable than we'd like. Sometimes we can ride that out, and sometimes chaos rolls in whatever we do. External factors beyond our control.

At those times, the more a system has been optimised for the expected stability, the more brittle it will be in the changes. The highly structured, efficient, foolproof processes, that are 100% reliable in the expected circumstances, begin failing and can't adapt. Competitors with looser systems that couldn't compete, may suddenly win everywhere because they are unconstrained by comparison.

So what's the answer?

Agility is the answer. Along with human judgement.

When designing your system, trust your users more than some ideal architecture, and where there's a choice leave them flexibility and don't box them in.

If something really cannot vary or fail, then that is a prime target for automation, and it should be removed from human contact altogether if possible. Let the humans have scope to do the things that humans can bring value to, and don't tie them down doing things where mistakes can't be tolerated.

Standardise where standardisation brings most value, and consider how far it needs to go.

However confident you may be that something will never change, think twice, three times, as many times as needed, before fixing it in stone. Consider what might happen if it did change, even if you think it can't, and have a fallback plan.

Watch for when process, or workflow, or your ERP, becomes a constraint, and face it early. When it becomes a reason why change is too hard or too expensive, it becomes a risk.

This is all difficult, because we always want to make success a pattern. We do what works, and we learn what works, and we try to repeat what works. And if it keeps working then we insist on it. Because success follows. And if we've had a hand in identifying what made that success happen then we're invested in it, too. And that stops us noticing when the world has changed and it's become a liability, often until it's too late.

Any time there's doubt, there will usually be humans who have a clear view, humans who can see the change.

Why draw attention to this?

As someone who makes a living from Epicor Kinetic ERP, I rely on organisations tailoring their systems, so in some ways I'm writing against my own interests here. Optimising is what I do.

But I do often have to push back, because over-optimisation is in nobody's interests long-term. I have seen often enough, by now, how confident assertion that something will never change ... turns into technical debt, rigidity in the face of market change, and makes other necessary future change into massively expensive risk.

Good ERP set-up should make it easier to change as the world changes, not lock you in place, and I hope I always advise accordingly.

The obvious type is the one who got a job with an ERP company after graduation or because it made sense as a job shift, and the ERP company trained them in all the things they need to know.

The other is the one who was doing something else in business, encountered ERP because it was needed for what they did, and somehow the ERP side took over.

This is the story of one of the second variety, me, and I tell it because it’s slowly occurred to me that it affects a lot of things about my work, and wider.

When I started work, I was part of a community that, for reasons that don’t matter here, banned computers. They also didn’t believe in education, so I started young, without going to university.

Project Management

It was a mechanical services company – plumbing and electrical – and my job was to manage long-running projects like the replacement of a heating system in a London church. So my first skill to learn was project management, loosely.

Systems Investigation

The owner of the company was a genius with heating systems, but paperwork was alien to him, and as a boss he was brilliant because he was quite happy to trust people to do what they showed themselves capable of and he didn’t do himself. At intervals, whatever I was doing, I’d get a call, sometimes late at night if there was a crisis for a client, he’d pick me up, throw me an instruction manual for some equipment and tell me to figure it out while he drove us there, and then I’d tell him what he needed to know to fix it. So the second skill was getting to grips with alien systems at short notice.

Bookkeeping and Finance

Then the woman who did the bookkeeping and payroll left the company quite suddenly, and I was asked to take that over. It was a paper-based system entirely, which would have already been quite rare by then. The elderly man who did the overall company accounts taught me how it was done, and the tricks for finding where the problem might be when things didn’t add up, and the boss taught me how to juggle the cashflow and what to say to people when the customers were slow paying and the suppliers not inclined to care. I also discovered that I hated accounts as a job, but it’s been another valuable skill. And the first lesson that what needs doing is a better job than what I want to do.

Payroll and Custom Tools

Payroll was tedious and repetitive, with a whole lot of engineers paid by the hour once a week. Although there was no computer, I had a graphic calculator left from double A-level maths, and it had a sort of Basic programming language. So I programmed it to do the payroll and save me time. I’d got to grips with the calculator’s capabilities because while studying it was annoying that it could do Cartesian graphs but not Polar ones, so I programmed it to fill that gap. That might have been the first skill that seems relevant to ERP, but I’m not sure things are as tidy as that.

Start-up and Design

Then came a couple of years trying to start a business from scratch. Plenty of lessons there about the realities of managing … well, everything. Supply chain, cashflow, accounting, sales. It was OK, but showed no signs of taking off without more investment, so we sold that and moved on. What I really enjoyed in that time was the design of everything, but unfortunately when there’s a whole business to get off the ground that’s mostly a distraction from what matters more. Still, it does matter, particularly discovering how people react to how things look and work.

Quality and Outsourced Operations

I joined a company after that, specifically to help with research and development and quality control. This was a small but growing company who had already gone from distribution to outsourced manufacture and had bigger ambitions. That was an excellent education in scientific process and how it has to fit in to commercial demands, and system design with auditability. As time went on, I became responsible not only for the design and performance of the products, but also handled the international supply chain, negotiating with East Asian specialist manufacturers and local sub-contract ones. That also took me into the world of international product regulation and standardised testing.

Excel etc

In all this time, I worked without computers.

Then that prohibition started to relax, and rigidly controlled computers were introduced. With a very short list of installed software and very high barriers to getting any more.

So part of my job became making Word and particularly Excel, later Access, do more than they were ever intended to do. Particularly Excel, once I learned VBA.

One of the first things was an entire purchasing system.

Later I created a rainwater flow-rate calculation system that needed all sorts of inventions. I hooked up Adobe Illustrator to Excel to digitise a British Standard for typical rainfalls, and invented a coordinate calculation method to cross-reference the digitised contour coordinates with postcode locations to create a master table of rainfall per postcode. I also ended up turning Excel into a sort of CAD software, in which users could import architectural drawings, trace the relevant parts, calculate the flows, and output reports with marked-up drawings. From Excel. Interesting times. Not the ideal use for Excel, and I knew it, but the edge it gave the company meant it stayed in use for a long time.

By this time the quality control system was running on Access, but outgrew it so the Access part became the front end to a SQL Server database, as slowly the rigidity around the computers loosened a bit.

... and finally, ERP

So by the time actual ERP came along, it didn't feel like a revolution. More, "so this is what doing things properly is like".

We used a simple ERP for a few years. Then, as it became clear that the rapidly growing company needed something more serious – we were manufacturing in-house and looking at doing more of it, as well as having double-digit sales growth most years. So I was part of a team set up to examine full ERP solutions and choose one. Many demos later, after much discussion and business modelling, Epicor ERP10 was installed.

Growing pains

The first shock at that point was that it was completely useless. The CEO hit the roof on discovering that the company had opted for installation without implementation, having been assured it would be completely functional as was, and of course an ERP that hasn't been set up is pointless. Hopefully that kind of selling doesn't happen any more.

So, with the cost already sunk, there was an unplanned project expense of as much again, fortunately with excellent consultants this time. Again, I was a core member of the team dedicated to the actual implementation. Certain specific areas of the business were my responsibility, and where data preparation became complex it also fell to me. At some points, Excel slowed to a crawl over the complexity and data load, and I learned on the hoof when it was better to get the data into a database and create procedures to systematically turn it from one form to another on demand, according to rules.

We also had training on customisation, which quickly became obvious was the key to making things work as we needed. Rather than go through the process of carefully documenting change requests, I found I was tasked with doing more and more of it myself, partly because I already knew the business and it took less effort for stressed team members to tell me what they needed.

And go-live happened on time, successfully. I take little credit for that, in case that isn't clear. Our lead consultant was brilliant, and I was very raw and just one of the team.

Actual ERP responsibility

As go-live approached, though, that consultant had words with management.

"You do realise," he said, "that once you switch this ERP on, you don't just leave it and get back to work? Someone within the company needs to be responsible for it, if not full-time then close to full-time."

And between everybody, they decided that person was me. Honestly, although it was a job role I had never known existed, let alone aimed at, it felt as though my zig-zagging previous career suddenly made sense as preparation for it. ERP is an intersection between business processes and software management and development. A lot of work is done by specialists in individual areas, but ERP "feel", I am convinced, comes only from being steeped in real business situations and creating systems for them, which was the common thread of almost everything I'd done.

The in-house years

So for some while, making Epicor ERP solve real-life problems in a growing distributor/manufacturer was my job.

We did some good things. Implemented the Epicor version of CRM and leveraged it, for which Epicor gave us a global customer achievement award. Early on I created an integration with the main shipping company we used, and then did the same again for a secondary shipper inside a week for a tight deadline, at which a visting representative wanted to know how we could do that when he couldn't get anyone else to. A lot of little things, too, to chip away at time wasted and resources misused.

We were a guinea-pig for a new add-on product, and I recall being part of a high-powered group gathered from Epicor, the new vendor and others, to decide how to make it fit in and do what it needed to do. As a result, I found out how to modify the accounting rules, which are ridiculously powerful and under-appreciated.

I learned a lot. Including that I liked the process of doing that better than I like a career or, for that matter being part of a big company. I like the development, the problem-solving, finding solutions that work in the real world and are durable.

And finally it all makes sense

Which brings me to where I am, doing exactly that. At the time of writing I still do a lot of it for that company, too, but now more widely wherever I'm needed. Because it turns out that some problems are best solved by a particular set of skills and experience that is hard to learn deliberately and tends to be acquired almost accidentally.

Software-as-a-Service, SaaS, or "cloud", has revolutionised a lot of things, because it has real advantages.

Crucially, though, a lot of those advantages are advantages for the maker of the software. And they are so compelling for them that it can overwhelm all other considerations. It becomes difficult for the software company to see how it looks from the buyer and user's perspectives. Even when they do see it, there's a strong incentive to present cloud as universally beneficial.

I am not anti-cloud. Looking back over my recent projects, three out of five are on cloud versions of Epicor Kinetic, and they're successes.

What frustrates me is the way the trade-offs of cloud are downplayed or avoided entirely.

Why you might choose SaaS, cloud software

At the "choice" stage, cloud is fast and low-cost. You can sign up, switch on, and it all works.

You don't have to buy equipment, you don't need the deep IT knowledge to ensure components work together, the Finance department doesn't need to sign off on capital expenditure for the equipment and licensing. You agree to an ongoing cost, which usually fits business cashflow and accounting nicely and is seen as less of a risk.

Then, in business as usual, you have outsourced the "difficult part" of running complex software, which saves on in-house skills. No database management and maintenance. No OS patching. No need to plan for capacity and performance and monitor servers.

For non-critical or replaceable systems, this is almost all upside. Particularly if the software is plug-and-play, to be used exactly as provided. You can be paying for the value you get every month and see the value, and any time the value isn't there you can stop paying.

Then, the vendor will tell you, there's immediate access to new features and improvements and a guarantee that you're not falling behind or missing out. Which always sounds good.

The myth of inevitability

Wrap that all together, and cloud will probably be presented to you as unavoidable. It's such an obvious choice that you'd be foolish to do anything else, even if anything else remains possible. It's what all the cool kids do, what the big hitters in your domain are doing, a sign that you're taking advantage of everything the future offers.

And MUCH easier to sign off, to boot.

But technologies aren't inevitable. Business models can come close to it, by making others unviable. When a choice is presented as the only one, it's usually because examining the alternatives is awkward for the seller.

What's in it for them?

"So, Mr Software Vendor, what first attracted you to the model that allows you complete control and ensures your customers pay you regularly?"

You don't need to be cynical to see the attractions of the cloud model for vendors. For a start, ARR (annual recurring revenue) is what ends up driving a lot of things, and without subscriptions the only way of achieving that is to constantly come up with new customers or additional things existing customers will pay more for. It's a lot easier and finance-market-friendly to forgo the lump payments in exchange for a commitment to keep paying.

And it streamlines the vendor's operations, too. There's no need to manage an endless proliferation of platforms and versions and maintain back-compatibility, support staff who know all of it, and deal with endless varieties of problems. Centralise it, and it all becomes simpler. And when something needs to change you can change it and know it's changed everywhere.

Look at this from the most convenient angle, and it's not difficult to convince yourself that these are all advantages for the end user as well. The financial health and capacity to manage must feed through, mustn't it? Isn't everybody better off?

The catches

Nothing is ever all "win". Everything is a trade-off, and it's up to us to judge whether it's a trade-off worth making.

So, most obviously, not having to pay out huge sums for perpetual licenses is balanced by the commitment to keep paying indefinitely. In most cases, that will end up being more, just spread out. That's not a bad thing if the value is there, but it is a trade-off.

We'll skip over the fact that once you're committed, the price can be raised and you may feel you have no option but to go along with it.

More subtly, the promise of always being up-to-date can be a treadmill with no off-switch. New features you didn't ask for, changes you don't need, the removal of features you depend on. Even features that are useful may arrive at less convenient times, requiring you to adjust on someone else's schedule.

Because that is the central trade-off with outsourcing the software provision. You give up control along with the worry and hassle. Which may be a big win, but isn't always.

Most obviously, there are some companies where control is vital. Sometimes there are requirements around data, sometimes around processing, or vital services that cannot be allowed to go down under any circumstances. SLAs are fine for most, and the likelihood is that problems will happen less often with core provision under the care of central experts, but the trade-off is that when there is a problem, there's nothing you can do about it. And for some that will never be acceptable.

Even for the average organisation, it turns out to be difficult to foresee the extent to which internal staff will be required to do the bidding of the vendor. It will become a department's job to do what the vendor says, under threat of all essential services failing, at regular intervals. Not for all software, but to the extent that the organisation and the software have moulded around each other, that job will increase. An IT department may be all ready to deploy something game-changing and have to hold off because an upgrade is hitting, even though it has nothing in it that's needed.

Which is another subtle pressure on the organisation to do less with the software than it's capable of, and was promised when signing up. The upgrade cycle will make unique features that give your organisation an edge feel more of an overhead, because they'll need testing and validating so often. That can be a good thing, forcing them to be justified, but it's another loss of control.

And ERP in particular ...

ERP software, in my opinion, is one of the classes where these trade-offs need more examination, in fact more examination than they usually get.

Because the big benefits of the cloud approach depend on consistency and standardisation, while ERP is explicitly sold on the basis of being able to mould to particular needs. And trust is more crucial than in almost any other class of software, because problems usually lead to organisations being unable to function meaningfully at all.

That puts ERP firmly outside the class of "just pay and use it" software that cloud is so good for. Unless you know you can work that way.

Right now it also feels maybe too pointed to say that trust also extends to being able to plan for the future knowing what a commitment to a software platform is going to involve.

Where does this leave users of Epicor software?

There are many happy users of cloud Kinetic that I know of. It's a good product, and with eyes open to all these things can be a winner.

Anyone looking for an ERP can consider, say, Epicor Kinetic as a cloud product and may well evaluate the trade-offs here and find it makes sense for them. And go into using it with open eyes, maximising the undoubted benefits and with plans for managing the price paid for them. (Usually the underestimated one, in my experience, is dedicated in-house knowledge and time, which isn't much diminished in cloud Kinetic use).

If anyone knows that the trade-offs are too negative, then better know as early as possible so other plans can be made.

The main reason I'm negative about cloud, as I say, is simply that the incentive is too great to pretend the trade-offs don't exist, that's all. And I'm always disappointed when they have been avoided rather than presented and faced, so this is my contribution.

Meanwhile, anyone using Epicor and now having to make plans for some kind of transition ... here we are. I shouldn't need to say here that Meta eight Ltd can help, should I?

Customisations can be drastic. More normally, though, they're relatively trivial, something like moving a field, hiding something you don't want to be a distraction, or adding an extra component. It's normal.

Either way, what most users then notice is that the result seems inconsistent. Sometimes they get the modified version, sometimes they don't. And that's usually because the most popular screens can be opened from a lot of different places within the menu structure, and each needs setting up individually to open the specific version of the screen. It's not even always obvious to the user where they've opened something from.

Most developers know this, of course. But even for experienced developers making things consistent can be tedious, with the risk of missing something.

So at META eight we created a standard dashboard to manage it. Nothing flashy, just practical.

And we've made it free to anyone who feels it might be useful to them, too. Everything you need, including instructions, is here:

META eight Kinetic Menu Management Dashboard

If you use software of any kind, you probably can’t help thinking about AI, because whoever supplies it is pushing AI on you. Everything is better with AI!

Does that include ERP?

Well, it would be odd if the hype didn’t get as far as ERP, but I get the impression that most ERP software companies are slightly conflicted, and there’s good reason for that. They don’t want to miss out on “new and shiny” (when have they ever?) and they don’t want to leave openings that others might capitalise on. But the fit isn’t quite a natural one.

So where does that leave you, if you’re responsible for ERP in a real company?

Should you be pushing for more AI, resisting it, ignoring it and hoping it’ll go away, or what?

How to think about AI in ERP terms

What do you have an ERP for, and why?

There are different perspectives on this, and a lot of different answers, but they usually boil down to “to keep track of everything that happens, and make the right things happen”.

What that means, is: an ERP must be rigidly predictable, or it isn’t an ERP.

In technical terms, ERPs are deterministic. Given certain inputs, the results must always be the same, and when requesting data, the results must always be the same. This is why they are often (wrongly) assumed to be Finance tools in essence, because they must be auditable, and all records consistent when they are.

As soon as you start working with modern AI, you realise … that’s exactly what it isn’t. That’s its magic, in fact, that it feels human in its whims and use of apparent judgement, even as it has inhuman speed and capability.

So introducing AI into the workings of an ERP, or thinking that AI in some form will replace ERP, is a category error. For all AI’s promise and brilliance, it takes away precisely what the ERP should be.

So AI is no use?

At this point, this sounds like an excuse from someone with interests in what ERP has always been, trying to hold back the tide. Everybody would like to think that their expertise is going to remain unaffected.

But this is more about where AI is going to successfully invade, not about whether it’ll happen.

And I think the best way to think about this is to consider AI not as part of the ERP, but as a sort of superhuman user of it.

An alien as a business butler

The dream that's being sold is something like this, mostly:

You don't have an ERP as you knew it any more. No screens, no dashboards, no hopping from place to place to see what's going on, no data entry, no scanning or clocking in and out. Like a science fiction spaceship, you ask your computer what's going on in the business, and it knows. It can explain to you, and give you whatever facts you need. It can make changes you request, and will suggest what's needed. It knows what everybody is doing without being a drag on them, and knows so much it's able to predict more before anybody could have known.

Which sounds great, and little by little we may get closer to that than feels likely from where we are now. I'm quite optimistic on that front.

BUT it won't happen by replacing the boring basics of ERPs as they are now. They have to stay in place (I say confidently, but with the caveat that tech may develop, possibly, that makes all my opinions a moot point – still this is as things are). They have to stay in place, because what this vision is really about is putting something better than people between the ERP machinery and the users. Not even the alien superintelligence of the AI we're assured is coming can conjure up knowledge from bad or inconsistent data, so the methodical structures that gather, store and connect that data are still needed.

Just as a mansion still needs a kitchen and ingredients, even though the residents have meals brought to them discreetly on demand.

Right ... but what about now?

What this means is that you, as someone responsible for an ERP, can't relax and let the machines take over. Your task, just as it ever was, is to maintain a system that's as absolutely reliable as it can be, and AI isn't going to help with that any time soon.

The important thing is the divide between deterministic behaviour, and judgement. Anywhere in the system where you need fixed results, AI doesn't belong, and you should be suspicious if it's offered. What AI can do is add layers on top of that, and threading between that fixed behaviour, that probably you previously needed humans for.

"What does this mean?"
"How should we respond?"
"Is there a pattern here?"
"Does this belong to this or that category?"

These are the kinds of things current AI is already good at, and can probably help with if embedded in an ERP.

Anything or anybody that suggests AI can make any existing part of your system obsolete should be viewed with suspicion. Ask a lot of questions, at the very least. Anything we currently know an AI can do ... it needs what your system already does for that, just as much as you do.

"We're not sure how this should work, so we're letting AI handle it" is a very bad sign, I probably don't need to say.

So the key is to be as rigorous as ever in the core ERP, and only allow AI features to access that core ERP in the way a user would. The ERP remains an ERP. And in an ideal world, the AI becomes that person the CEO asks for information rather than ever logging in themselves.

And this is coming

We are starting to use AI tools in ERP work.

As an enhancement to OCR for document input here.
To choose between categorisations there.
To create summaries for notifications in this case.
As a check for patterns in data in that.

Little things, mostly, conveniences and removals of drudge work, with certain key elements, such as

• Lack of clear definition what should be done in each case (otherwise an algorithm works better)
• Structured options provided for action, only free-for-all if any resulting action will be by human decision
• Clear oversight by humans, and fallback and override by responsible humans

If we can do this already, a lot more will become possible, without any doubt. So I don't think there's any avoiding it.

And notice I've barely touched on what's needed to actually implement these things, and how to make them work reliably.

TL:DR

AI is likely to be useful in your business systems, if not now then soon.

AI is not going to replace your ERP in any respect, and if anyone is suggesting any such thing, keep your distance. Any useful application of AI needs what your ERP does.

Think of AI as a superhuman user of your ERP, not as part of it, able to do the repetitive tasks that are too ill-defined for normal computer processes, and too overwhelming or too dull for humans to be reliable for, and you'll be best able to judge whether a proposed solution is snake oil or genuinely useful.

It will be an ex-UI.

If you're running Kinetic on-premise, you obviously don't need to panic, because you can choose when you upgrade to the point of classic not being supported. If you're wise, though, you'll be making plans even if you haven't started already.

If you're a SaaS user, you have a hard deadline. Any classic screens you're still using are going to become unavailable, like it or not.

If you're OK with that, skip straight to the how-to. (Yes, that's a link.)

For the rest of us ...

A moment of silence

I like the classic client. It's still my preference, try as I might to get used to the new Kinetic client. It's robust, proven, adaptable.

You can fit a lot more into a small space, and it's clearer, generally, which screen you're in. There are more developers, because it uses the same basic code and tools as the server side of Kinetic, and they're Microsoft standard for the most part.

So I'm sorry to see it go. But here we are.

I come to bury the classic client, not to praise it. Some say it wasn't ambitious, and that was a grievous fault.

The Kinetic UI is ambitious, and because it's a massive step it's been hardest to accept for those most familiar with the old client. It didn't help that the ambition ran ahead of the reality for so long, meaning that users and admins got into the habit of retreating back to the familiar.

If you're resisting change, this is for you.

It's time to let go. The Kinetic client is good now, though I for one am not blind to some shortcomings, and you can do this.

You know it's a big change, not a trivial one, so that gives you an advantage. It's the users who think swapping out one set of screens for another is just an admin task are the ones who get bitten by the complexities they didn't expect.

The Kinetic UI is completely different.

It's different underneath, it's different in the tools you use to modify it, and it's completely different to use and look at.

Don't let that blind you to what it can do, because you're looking at what it isn't. Arguably you can do more with it than the classic client. It can be great, and very flexible. The price you pay is not that you're getting a lesser system, not in the least. It's simply the sheer amount of change.

Vanilla Kinetic screens all look much the same, and nothing like users are used to. They take up far more space, and usually need more clicking.

DO NOT be tempted to try to get over that, and put them back how everybody will say they want. Yes, you could. Or make them even better. Don't. This is a whole new UI, and users need to get used to it.

Treat this as a chance for a re-set.

A plan of action {#plan-of-action}

1. Get users to use the new screens in the Kinetic UI.

If you're doing a big upgrade from an older version, treat it as an implementation project, not an upgrade. Push users into a Dev system with all-new UI, and do scenario testing. If you're already on a recent version of Kinetic, you can switch screens progressively, starting with ones that'll matter less. If they're using them live, it'll be quicker finding out if anything needs adapting.

2. Make a list of the existing customised screens.

Do not start customising their replacements. Just make a list.

3. Divide the list into two types:

Trivial additions of non-standard data.
Anything else.

4. Check with users that they still need the non-standard data for each of the first set, and add it to a Kinetic version.

Treat those new customised screens the same as the completely standard ones. Either as part of the scenario testing or within the phased roll-out.

5. Deal with the second set, the more or less heavily customised screens.

Be prepared for additions to this list, if users find other Kinetic screens change in ways they can't live with.

Actually customising those screens ...

First of all, don't. At least not yet.

Whether you're doing a phased roll-out or a big upgrade, pull these out into a development system as a separate thing, and have a user seriously try the new base Kinetic screen with no customisation at all.

The new screens are so different that the thinking that led to the old customised screens probably won't apply any more, so the old solution will be a bad guide to the new one. Take time to work with users to see how the Kinetic version works. Push back a bit, identify what the real gaps are, not what they expect them to be. There may be more, or there may be less, but they probably won't be quite the same.

Then, finally, solve those problems.

But do it in a Kinetic-native way. If you try to duplicate what people have been used to in Classic, it'll be headaches all the way, far more time, and won't work as well. New thinking is required.

And, of course, Application Studio skills.

OK, what about that new thinking and those skills?

That's another subject, for another post. If you can't wait, feel free to get in touch.

So please don't call me about running an implementation for you. It takes a skilled team, because there are more things to configure than one person can know. And a project manager, which I am not. There are consultancies that specialise in implementations, and for Kinetic there's Epicor themselves, of course. Our little business doesn't compete with them.

I have been in the thick of some implementations, though, enough to talk about it.

So here’s the thing about implementing an ERP …

Businesses do it because they’re growing or changing, usually, which means they’re busy.

They settle on an ERP, hopefully making a wise choice and not allowing “shiny” or ideas of prestige to sway them, and are OK with the cost. ERPs are expensive, but it's going to pay for itself in efficiency and accuracy.

Then they find out what implementation costs. And they’re shocked, but they sign that off too. After all, they are going to be in the hands of experts, and better to pay experts than try to do it themselves.

They’re busy. Busy with the business itself.

Then the experts come in and get started, and not a lot seems to happen, because they all say they need time with the busiest people.

What was going to be experts coming in, seeing what needs to be done, doing it, and training everybody on what to do ...?
It's not that. It's meetings. Requests for documents, procedures and data. There's a lot of waiting, because they're waiting for the people in the business to do things, and the people in the business are busy.

The experts are used to this. They'll tell the business what the business needs to do, and wait, because this is what always happens. Time passes, and bills tick upwards. It's not the experts' fault, because they can't work magic.

So what happens?

At some point frustration spills over, because these are the experts, and they should be doing what they need to do, advising and getting on with it. At least as far as management are concerned. The whole project turns into a drag on the business, costing money and acting as a distraction and a drag on making money.

So maybe more or different experts are needed, to break the logjam? At this point, the cost seems secondary because it’s running away anyway.

Sometimes a different expert CAN help (this is the stage at which I’ve joined a few times), but not because of the expertise, as such.

What's the actual problem?

The whole point of an ERP is to mirror the business itself. That means most ERPs, including Epicor Kinetic, are complex, flexible, and configurable, because no two businesses are the same. The system, as it's sold, won't even work without being set up to match the business, and that's before you start any gap analysis.

Any honest salesperson or consultant will tell you all this. They don't hide it or cheat (normally). But the business buying the system often doesn't take in the implication for the process of getting the ERP up and running.

Which is ... the experts, the consultants, know the ERP, but they don't know the business, and they can't. It would help if they could embed themselves in the business, but even then they can't know everything about all of it. And at consultants' rates it's not likely to be signed off as an idea anyway.

There is no real way round this. What an implementation is, is:

• Finding out the processes and the data (which needs the staff).
• Matching those to the ERP (which consultants can do).
• Configuring and customising the ERP (which is what everybody expects consultants to do).
• Testing whether it does the right things (which needs the staff).
• Training and preparing (which needs both the staff and the consultants).

Most of the time and resource is needed from the business itself. And the business is busy.

And nearly all the problems everybody hears about in ERP implementations are because this is a very hard fact to accept, and a lot of businesses get a long way down the road before they can accept it. I suspect the core reason is that nobody involved in selling and implementing ERPs feels they can afford to be as up-front as it would take to avoid the problem, for fear of businesses shying away from doing it at all.

So what's the answer?

The answer is that there is no answer. This is just the ugly fact of ERP implementations. When a business accepts that they're disruptive, and realistically faces the trade-offs needed, that's when it can make the best of it.

A good ERP implementation needs maybe half the available time of the best people in the business, roughly speaking, the people it can least spare. Because it's their input that makes the ERP actually do the right things in the right way. The job of management, having decided that the ERP is going in, is to work out exactly how those people can spare that time, over the timeframe they can spare it, and keep the business functional for as long as it takes. Getting it over quickly means more time out, and skimping on the time out means it will take longer.

As I say, implementations are not what I do. There will be experts who say I'm being cynical and negative in this, rather than realistic.

Maybe so. But think of it this way: if you go into a project assuming what I've said here is gospel truth, you'll be prepared in a way that makes it more likely to succeed. If you don't, what happens if you come to a point where it does look like this? Can you afford to bet it won't?

OK, but is there ANYTHING that will help?

Yes, as long as you focus on dealing with this basic fact, rather than looking for something to make it go away.

The biggest thing, probably, is project management and accountability. Visible, in both cases.

I've seen that work extremely well with sticky notes on a huge whiteboard, so it doesn't need to be elaborate. If people are scattered then you'll need a software solution, almost certainly. It'll feel like more admin, which is the last thing anyone wants, but it pays back when done properly.

If it is digital, then it can pay to have a huge display somewhere everybody passes, that shows what's going on and who is responsible for each bit that's going on. This works well for scenario testing, as a specific script passes between departments. Everybody can see if something is being held up because nobody has got to it. And everybody can see the list of things that need fixing, too.

And it's the fixes that I can help with, as I mentioned that I've come into implementations at later stages a few times. Once the business itself is driving the cycle, as it has to do, then it can quickly come to seem worth having a nimbler developer in the loop, where the same person can discuss what the fix should look like and get it in place, in a timeframe in which a team of consultants might still be gathering requirements. That team of implementation consultants never runs out of things to do, so they rarely mind another pair of hands.

But the business itself, and the people in the business, can't escape doing a lot of the work.

Harsh but true.

– was always that it was so heavily Windows-based.

I recall an Epicor sales person telling me that “Epicor is more Microsoft than Microsoft”.

For all the drawbacks of that all-in-on-a-platform approach, it made customising the system straightforward. It was built on Microsoft tech, with Microsoft tools, and all the standard Microsoft and .NET development ability was right there within the system management. If Windows could be made to do something, you could get your Epicor system to do it.

… it isn’t like that any more, really.

It’s taken a while, but I’ve realised that, as an Epicor developer who makes a living making Epicor Kinetic do new things, my mindset has shifted because it’s had to.

The big shift to a new User Interface is part of it. That is web tech now, not Microsoft. Any hard-earned skills making the classic client sing and dance are now outdated.

But it’s only part of it.

Modernisation, a new emphasis on running in the cloud, a shift to SaaS, and demand for things to be both secure and inter-compatible – all mean that the system itself now has a very different basic philosophy. It’s far more locked down, more restrictive technically, focused on bespoke customisation capability rather than common platform tools, more modular and less tightly coupled.

Bluntly, you can do less in an Epicor system than used to be possible, and it’s become a moving target so it’s not wise to push the boundaries.

But it’s not all bad, honestly.

The key to all this is the decentralisation. Kinetic itself runs on REST APIs. Information shuttles around via calls between standalone services, because that’s how anything built for cloud works (excuse the simplification to make the point).

That means that at the same rate it’s become harder to make a Kinetic system do what it wasn’t designed to do, it’s become easier to link it to other things. Which opens up different approaches.

It’s nice outside, you’ll like the freedom.

For years, I reckoned I could make Epicor systems do almost anything.

These days, I find I’m shying away from that, in favour of getting something else to do it. Quite often there’s an existing product or service, and when there isn’t I can create one. Let Kinetic do what it does, and call on something else for the new thing.

It’s not quite as simple as it sounds, because Epicor development work is still needed to connect and use whatever this outside service may be. But the tools for doing that are good, and stable, and not going anywhere, and a standard set of techniques work well across a wide range of possible needs.

And the external services?

I’m enjoying creating some of them.

• Bespoke mobile apps.
• Mini print servers for centralised automatic printing.
• Links to external specialised data.
• AI processing

And there are so many more already out there: CRMs, carrier automation, data APIs, mapping, webshop services, the whole Microsoft landscape of services and products that most Epicor customers are already using … there’s no end to the possibilities.

I’m not sure how I feel about this proliferation in some ways, particularly as more and more of it has subscriptions, but this is the way things are. And Epicor capabilities are not free.

You can’t avoid the disruption, you might as well enjoy the benefits.

If you were using Epicor ERP10, you may have noticed the downsides I covered as you’ve been pushed kicking and screaming towards Kinetic. For many, I know, it hasn’t felt like an improvement, particularly admins and developers. And it’s been a bumpy ride even for those who could see the benefits of the new system.

This, I think, is where we all should be looking. Epicor had to modernise, and the modern system has a lot of advantages. We should maximise those, not fight them.

Don’t try to do things the old ways too much. Yes, BPMs still work well, BAQs are still powerful. Functions are (in my opinion) the best Epicor feature ever.

But when you’re tempted to customise, first step back and look at whether there’s something external that could be leveraged. Or even something unique to your company that you have control over and can connect to a Kinetic system that remains easy to support.

That's totally fine. Don't let any experts tell you it isn't. Not everything can fit your unique organisation and processes just with configuration. But there are better and worse ways to do it.

I'll detail below the basic structure I use, and why, based on first several years as an in-house Epicor system admin, then as a consultant developer. It's the experience of seeing things from outside that's made the difference for me, because although nothing about what follows is inapplicable to in-house staff, they're able to get away with less whereas someone like me can't (or shouldn't).

(This follows from the previous post about robust maintainable work on Epicor systems.)

Documentation FIRST

For trivial changes, I create a single document, titled with a ticket number and identifier. Often nobody will ever need to see it except me, but it then exists if anybody does. It usually doesn't have much in it, but at a minimum will list the components of what was done.

For anything more serious, I create a repository (I use GitHub). This is not because git is well-suited to Epicor customisation code, because it isn't. It's because I've found the flexibility of a repository, and the inbuilt tracking, works well just as a record of a project. Markdown files, with links, are a good, simple, and tech-friendly way of creating documentation and making notes, even if I include no code at all.

To start, there's a ".md" file for specifications, which can be copied from what's provided, or written from scratch if needed, with links to anything else that's relevant.

Note: if I am sharing the repository with whoever has commissioned the work, which is usually the case, this is an excellent way of making sure we all understand what's meant to be done, too.

Then there's a notes file, plus one file for each of the commonly-needed type of component a solution requires (BAQs, BPMs, Dashboards, UD Fields, User Codes, Screen Customisations, Functions etc). Notes can often be started immediately, with anything that's useful but more temporary or tentative than belongs in specifications, but the others stay empty. They are there from the start to minimise any friction noting down anything as it's created.

The Read Me file has links to all those others in it, and is reserved for detailing the overall structure of the solution.

Put things in the right places

Summarising the above linked post: there is usually a best place to put most elements of an Epicor solution. Logic in Functions if possible, triggered by BPMs, with only interface changes going in screen customisations. If custom data needs to be stored, do it in new UD fields rather than trying to shoe-horn it in to existing ones.

(For the reasons behind this, read the other post.)

As these elements are created, list them in the waiting Markdown documents.

If there are parts that are not obvious from the things themselves, or wouldn't be clear to a competent Epicor admin (or me when I come back to it) then the explanation also goes in those files. For example, I often create BAQs where the conventions in the field labels are important, because the BAQ will be processed using them by a function, so those conventions need detailing.

Any particularly significant code can also be included in a ".cs" file in the documentation, as it can be easier to link to explanations of it, and make reference easier when reviewing without direct access to the system, but the essentials are the explanations rather than the code.

Make it testable as well as understandable

This is the critical part, and hardest to explain because it's more of a mindset thing than a set of rules.

As an example, suppose I have a piece of logic or action that my customisation requires.

I put it in an Epicor Function, for the reasons I've given. But more than that, I try to choose a recognisable name, and I also try to make it properly standalone, which means thinking carefully about the parameters.

A good function, ideally, doesn't depend on anything you can't see from what's passed in or out, so it's better to pass in parameters rather than have them implicit in the workings. Restrictions on how they work mean I can't be rigid about this, but it's the ideal.

Similarly, as far as possible I make it impossible for the function itself to cause an error. I wrap everything in try/catch blocks that I can, and pass any resulting error out as a response parameter, including detail of the function it comes from so that whatever calls the function can decide what to do about it. That means that any error that does occur won't be a mystery, because it will contain the record of where it happened.

That's a minimum. The outcome of working this way is that anybody, including me while I'm working on the solution, can call this function, pass in whatever test data we want, and see what we get back – including an error, if any. I'll come to ways of doing that, and improving the testing, later.

Where a function acts on data that isn't a simple already-existing record, I prefer to create a BAQ for the data, and pass in the name of the BAQ and any parameters to the function, so the function can call the BAQ for that data. That is less efficient, but pays back in clarity and maintainability. It means the data retrieval can be tested and adjusted independently, including by someone without all the knowledge necessary for working with the function itself. If there's any unexpected behaviour, the BAQ can be used by itself to check what data was being worked with and why.

Note that it is vital to document which BAQ to look at in which case, and how any conventions work! It's only clear and maintainable if people know it is.

Ways to improve testability

Test-driven development isn't really possible when working with Epicor systems, but a loose aim of working that way helps, and there are some things that can be done.

More can be done with functions, which is one of the reasons to prioritise them. If they're constructed cleanly, it's often possible to test them by using the "Schedule Epicor Function" screen. One other benefit of this is that you can add code within the function to add entries to the SysTaskLog table when the function is called this way, and then you can check the System Monitor and see a list of whatever you've chosen to log. That also means that anyone else working with the function has the option of testing what it's doing and seeing the granular results rather than simply the output. It also works equally well with on-premise and cloud systems, unlike writing to the App Server log.

Other ways of testing functions which I won't detail are: using a tool like Postman to call them via REST, and creating an updateable BAQ that uses the function within the GetList method to take data from the system (or BAQ parameters, or a combination) and return the results to calculated fields. Whatever method I use, I try to make sure I can isolate the function and check exactly what it's doing, and so can anyone I pass the work to.

For functions which perform permanent actions, like sending data to an external API, or updating records in the database, it's useful to provide some kind of "test" switch. This can be the "Debug" option provided for Epicor libraries, or an extra parameter (ideally with a default setting). When functions are created this way, they can be tested with the switch enabled, and the permanent action bypassed. Normally when this is done, the logging or return message should be set to give an indication of what would have happened, such as a dump of the data sent to an API. It can work well to send this in a pretty form to the error message, because then testing is possible all the way through to the user interface, if the errors are handled normally – the testing user will get a pop-up message saying "this would have happened" when they perform whatever action triggers the new behaviour.

BAQs obviously are useful because they are already inherently testable, though some of the above can be useful when creating updateable BAQs (which are also underrated as a way of isolating behaviour in a custom solution).

The same thinking can be applied to screen customisations, for example with a "test" sub-version, or a "test" checkbox only visible to people with developer credentials.

The overall aim

Rather than getting bogged down in the weeds of my current preferred methods, I'll zoom out at this point and assume the knowledgeable reader has seen enough of the specifics to get the idea of what they are.

What this is all driven by is one aim: however intricate the custom behaviour required, it should be possible for a reasonably competent person to come to it with no outside knowledge, read somewhere what it is meant to do, how it does it, and check for themselves that it is doing that wherever they need to dive in. Ideally, those permanently on the staff of the company using the system should be able to do that at any time, including when modification is needed due to changing needs.

That means thinking at each stage of solving the problem not just about how the system does it, but how the people who work with the system are going to manage it. If it needs extra work, or slightly less efficiency, to provide ways of letting them interact with each level of the solution, and keep as much as possible in understandable consistent chunks, that's worth doing. Not just worth doing, but pays back.

The difference is that I've given them something they can use, they can understand, they can feel they depend on, and haven't thrown some black-box functionality at them and then retreated out of reach. It pays off increasingly over time, too, as it isn't rigid. If things need to change, they can change them, and if upgrades cause problems they have ways of checking where the problems are occurring.

Some independent developers might argue that I'm making trouble for myself for no good reason, and that I'm leaving future work on the table by making it less likely they'll need to come back for fixes. But so far people seem to come back for new work instead, and that feels better to me.

But Epicor themselves, and almost all consultants, will tell you – don’t do it. Or only a bare minimum.

Why?

Because there are few guarantees about non-standard workings. Not that they’ll keep working as intended, not that they’ll upgrade cleanly, not even that your processes will stay consistent. If you do things the way the standard ERP does them, you have the backup of the ERP’s creator. Within reason.

But my job is customising. So what can I do?

Here I am, having built my business around customising and automating Epicor Kinetic. So, below, I’ll describe my most recent way of working.

Not only do I meddle with the standard system, I also can’t reckon on being around in the future. I work on a project, and that might be it. It had better work, it had better be reliable, and it had better be clear for anyone in the future to deal with.

Almost all the work I do is for companies who have very capable Epicor admins in-house. Far from trying to keep my professional secrets, I can only succeed if I’m transparent and create things they can use for themselves. Because they’re still supporting the system after my project is done.

Standard good practices like clear specifications and documentation help, of course. Everybody knows that, even if they don’t actually follow those practices.

But Kinetic itself can be used in better ways.

Keep things where they belong

Epicor has done a good job, in recent years, of creating tools with distinct purposes for customising, even if they do discourage their use.

There are BAQs for data access. Customisations (“layers” in Kinetic-speak) for interface. User Codes and UD tables for custom data. BPMs, method and data directives, for triggering actions. SSRS and routing for reports. Functions for … well, that’s where it gets interesting.

Leaving functions aside for a minute, the key to a maintainable change to Epicor Kinetic is to only use each of these for its core purpose. No business logic in the interface, ideally no logic in BPMs even, but cleanly separate out what needs to happen and do it in the right place.

Keep things basic

When I say “basic”, I don’t necessarily mean “simple”. Simple is best where possible, but it’s even more important to get to the root of the workings, and work with what is least likely to change.

I find, for example, that widget-based workflows have a habit of breaking, because they have to depend on high-level assumptions about how the system is going to keep working, and upgrades often change things. Code that carefully uses the core Business Objects that the system exposes, in ways standard for the platform it’s built on, is more robust.

I sometimes talk to clients about working “with the grain” – finding out where the system works most naturally similar to what they want to achieve, and leveraging it, rather than trying to override anything.

Where something is completely different and the system doesn’t cover it at all, it’s often better separated out completely.

And, do things in a repeatable and predictable way. Don’t create solutions to be clever, create solutions that are, as far as possible, just what anyone competent would expect to see. Not least yourself when you come back to it.

Use Functions

“Epicor Functions” have changed the way custom logic in Kinetic should be approached. Because they’re isolated and reusable, they allow custom logic to be kept in one place.

In general, what you can do in a BPM, you should normally do in a function and call from a BPM, unless it’s trivial.

This is not about the system itself, or any efficiency or capability, it’s all about the humans responsible for the system.

So this is what I do

When I have a project for a company, most types work like this.

Create a Function Library for the core workings.

A whole series of posts could be written about how this is done in itself, but the point is that all the logic is in functions in this library, and ideally nothing repeated. And nothing should need changing unless the logic needs to.

If there are company-specific details that need to be used by those functions, and might change, they are stored in a dedicated set of User Codes. Never in the code itself. So, for example, with a REST integration, the endpoints and access details are in User Codes.

If the function assembles non-trivial data from the system to put somewhere, either pass it into the function from outside, or call it in via a BAQ. This is controversial to some, because it’s less efficient (slightly). But it has the massive advantage that other Epicor users and admins can access and adjust that BAQ, and therefore the data used, without needing to know anything about the logic or the code so can leave the functions alone.

If it’s an integration, either calling on an external system or callable from an external system, make all calls via the function library.

Where needed, use method and data directives to call the functions when triggered by system events.

Where needed, show new and different data to users in the interface and allow them to interact with it.

If something really radically outside the system scope is required, build it elsewhere with an API and call on it from functions.

What does this achieve?

What I’ve realised is that when I, as an outsider, create a solution for a company’s Epicor system, success depends not just on the end users. My real customer, usually, is the in-house expert who has to maintain everything.

By creating a modular solution, I give them additional functionality, not just a tick in a list of things they’re asked to provide.

A good function-based system can be tweaked, re-used and extended, because the functions are usable alone. And if architected like this, they’ll be robust and flexible enough for it. So it continues to be a win beyond the initial scope, long after it’s been signed off.

It takes a different kind of approach to build for maintainability, and I have yet to see much discussion about it from developers.

Another of these posts can go into more detail about how the components are structured.

If, after that, you are wondering about an independent expert (yes, like META eight), you may wonder what you're letting yourself in for.

You may be wondering because you're the person responsible for the Epicor system at your business (Hi, I've been in your shoes!) and while you could really do with help of some kind, you really don't want to be responsible for expense and things going wrong or not getting completed that are out of your hands. And, whether you admit it to yourself or not, you worry that you may undermine your own position in some way by showing up a lack of competence or looking less necessary.

Or, you may be responsible for a wider part of the business, or all of it, and this is on your mind because you have a problem to solve.

There's a simple short-cut if you want. Talk to us. Talk to me, in fact – I don't bite, and I don't push. If you don't like what I say then I don't chase either.

But that said, here's what we, at least, aim to do for you.

What we like is a defined need. That's usually a more or less complex project related to your Epicor system outside your business-as-usual. We take that, and give you a solution for a known price (give or take how flexible you want to be about what you're asking for). We also make sure that you know how it's done and how it works, so there's no subtle elastic keeping you tied to us for anything related to that in future. As a business, you pay for results and new capability, not more staff.

Personally, I've yet to do any work for a company that didn't have its own capable Epicor experts in-house, and that's the way I like it. A system as capable and complex as Kinetic needs at least someone who knows it well and can configure and develop.

When you're in one environment, though, projects and needs do come up that are new. What someone from outside gives you is instant experience on tap when you need it. And you can benefit from that experience not only directly, in more quickly and reliably getting a particular thing done, but also indirectly as you see how it's done. Far from being a threat, that's a boost.

Effectively, you have training thrown in, as well as projects completed that otherwise would be a problem.

A good independent Epicor consultant/developer is a force multiplier. Not a replacement for anyone you have, not even like an extra member of staff, quite. If they're good, they're more than that – you have, on-call, experience and capability that's different to the kind achieved by being very deep into one particular system. And that not only lets existing staff focus cleanly on what they're most needed for, it gives them access to new knowledge as they find they need it too.

OK, you say, so how do we know whether a consultant or developer is good?

Well, that's quite easy and low-risk, too. You try them with a small project. That's the great thing about independent people, too. No big commitment needed, and if it doesn't work you haven't lost much.

Chances are, however good your staff are with Kinetic and Epicor systems, you'll at least consider getting some expert help at some point. You may be here because that's what you're doing right now.

1. The safest choice

You can go right to the source, and get Epicor Professional Services to assist.

Nobody has better access to knowledge, tools and the inside track on where your system is going. Nobody has a wider variety of experience of companies using Epicor systems, so it's unlikely there isn't at least somebody who has a good solution for whatever you want. And they'll guide you in the most normal way of doing things, and the least likely to trip you up as the system is upgraded in future.

2. Official partners

Epicor also have official partner consultants.

These are usually staffed with people who have worked for the biggest companies, in a lot of cases Epicor. They pay to be partners so they get a lot of direct support. To do that, they usually have to be quite big, which means there is massive breadth and depth of experience.

I can't vouch for many partners, but I know one example I've worked with a few times who are excellent: Clear Business Outcome.

These two options, Epicor and their partners, are the best options for a whole lot of work, and definitely for big projects.

If you're implementing Kinetic from scratch, doing a major upgrade, shifting to the cloud, anything like that, you need the big guns. You may also choose to go that way anyway – you'll have a project manager, an account manager, and a horde of specialists and developers all with their own area of expertise, and they WILL get your work done. They have tried and tested processes and systems, and they won't be derailed by the unforeseen, because there's plenty more resource and expertise beyond what you see.

3. IT Agencies

Some agencies do have departments specialising in particular ERP software, including Epicor. While they'd prefer to find you a new employee, they will help get you a contractor or specialist if you ask.

Two I've worked with are IT Works and Washington Frank.

This way, you get vetted people, and the backup and coverage of professional agencies who know all about putting specialist teams together and finding the right skillsets.

4. Independents (yes, like META eight)

These are last on the list for a reason. They're frequently the last choice, because they feel like a risk.

They're the individuals and little teams who have clear expertise, otherwise they wouldn't be doing the work, but don't have the reputation and support structure of the big consultancies, so you can't be sure how good they are, or what you might be able to do if the work isn't good enough.

Choosing –

Something to realise at this point is that you are NOT choosing a type of person here. The particular individual rolling up their sleeves and getting stuck into your Epicor system could be exactly the same through any of these routes. Not only do the same pool of experts change roles, and move between companies and try self-employment (some liking it, and some moving back to the security of a bigger company) ... there is sub-contracting too, and you may find (or never know) that an independent is doing crucial work even though a big consultancy is handling your project.

And that individual is probably paid much the same whether they're working directly or via another route, which puts the spotlight on the elephant in the room of this discussion: you will pay more for the same work from a big consultancy.

So are options one and two above bad value? Of course not.

What you get with a big company is all the things that are not the actual changes. Basically, security and peace of mind.

You get management, processes, back-up and redundancy. You can put a crucial project in the hands of a consultancy like this and nobody will blame you if it isn't handled well, because it's their reputation on the line and their processes controlling it. They have ways of doing things, people for each thing that needs doing, including liaison and management of what's done. That costs, but it pays back in controllability, predictability and insurance (not literal insurance, because we should all have that, but the plans B, C and D that are sometimes essential). The backbone of any IT project are the advisers and developers, however it's done, but as soon as something scales up there needs to be a lot more people doing things that are not that core work, just to make it all work smoothly.

The big message here is: do NOT opt for an independent to save money. That's false economy.

And here I am, speaking for an independent consultancy, saying that.

What are the good reasons companies have for choosing us, or those like us, or contractors, then?

Well, the clue is in what the big options do well, and whether you want that. If you know exactly what you want to achieve, or want to move fast, or have an edge case to solve that isn't common – the predictability and management layers of a "proper" project team may feel as though they get in the way. The thing I hear most from clients is "I just want to be able to talk to the person doing the work".

That might be because you have your own team, and trust them, and just want a bit of specialist help or more personnel for a while (that's why the big consultancies use independents and contractors too). Or it might be that you want a more personal approach. Even that you want to try something completely new that others have told you can't or shouldn't be done, and you think they're wrong.

Companies come back to us regularly because they like being able to say "can you just ...?" I'm pretty sure.

As I say, I'm terrible at sales.

We know who we can help, and the kinds of things we're best at, and it doesn't make sense to pretend otherwise. If this helps you realise that you'd be most comfortable with a bigger player in the Epicor space then that suits us too.

Once the novelty of a machine being able to give answer in poetry, or whatever, has worn off, though, you may well ask what it’s actually useful for in business.

Well, things are moving so fast that this post may be outdated very quickly, but there are clues to the kinds of things that become possible (or just easier and cheaper) when you have access to these systems.

This is my experience, as an independent ERP developer, an AI semi-sceptic.

Using the APIs

Firstly, to be serious about this, you need to get out of the browser and work with the back end of the systems.

For now, as of writing, I’ve been using OpenAI, which is ChatGPT. The principles should be the same for any others. You need an account, it will start to cost, and there is some technical setting up. I won’t get into that here – it’s easy enough to find details online. If you’re thinking “business”, none of it is scary or off-putting.

So far, I’ve successfully used the same APIs as part of projects in Javascript, Python, C# and in Microsoft’s Power Automate. And for at least two of those I really count as an amateur.

Doing it the API way strips away some of the magic. Which is good and bad.

When you make a call to a Large Language Model (LLM) chat API, it becomes clear that you are not conversing, and there is nothing like a person on the other end. It’s become a cliché, but it really is a glorified autocomplete. Each call is a distinct one-off event, and it doesn’t remember anything from one to the next that it didn’t know already. So getting good results means giving it plenty of context, exactly the information it needs to give the kind of answer you’re looking for.

And generally, it doesn’t know any of your specific information. If you’ve told it once, it still doesn’t. Not even if you’ve told it every time so far.

So calls to an LLM API mean constructing a prompt well, above all. And being completely clear about what you want back.

Chatting

As a start, people generally want to reproduce the “chat” experience, I notice. Maybe people find it useful to have a bot answer questions, and you want it to be under control within your own system.

Without special sauce, beyond the scope of this post, it will only ever be very generic, but I won’t judge. People like chatting with machines, at least for the moment.

To give the user the impression they’re having a conversation, the trick is to keep feeding back into the API the conversation so far.

Outside of the calls, you can save each user query and each AI response, building up an array. With OpenAI’s system, this works as the data pairs “role/content”, where “role” alternates between “user” and “assistant” (or whichever equivalents you pick). For each new user input, you send the entire set as part of the prompt, finishing with the newest. That means that as the conversation progresses, the LLM can tell what response is most likely to be wanted next.

There are two hurdles.

First, it helps to provide context and a persona to the LLM to tell it how to act. This can be done by keeping additional messages at the beginning of the queue with role “system” – from “You are a helpful assistant” to increasingly specific characteristics and background information.

I’ve found that simple personas like “knowledgeable but sarcastic assistant” are surprisingly successful, if that’s the kind of thing your users like.

Second, each call has a size limit, and bigger calls are more expensive, so unless you can guarantee each exchange will be brief, these queues of past messages will need to be cut down periodically. You could do this by progressively deleting the oldest, but I have also had success with getting earlier parts of the conversation summarised and added as context messages, like the persona one.

It’s also a good idea to decide when and how the message queue gets flushed, so irrelevant context doesn’t keep getting sent, adding to the cost and worsening the results.

An aside on chatting to an AI while at work

I was a bit dismissive, back there in the last section, wasn’t I? Implying that these chatbots aren’t really helpful.

Can’t they do all sorts of useful things? Write all your code?

Actually, to an extent they can, if you don’t get your hopes up too high.

ChatGPT and OpenAI don’t know anything about the workings of Epicor as far as I can tell, so they can’t do much of my development work. But they do know about C#, .NET and Microsoft tech, so requests for boilerplate code can be quite successful. If it’s routine and generic, it’ll be pretty good.

Of course, the problem is that if you know enough to ask for routine and generic, you can probably put it together yourself without much more trouble. But anyway, the potential for being a bit lazier is there.

Where I found it more useful was when I switched to unfamiliar languages. I’m rusty on Javascript, so it was handy to be able to ask for code when I got stuck. The key is that I needed to know what to ask for, and if I didn’t know any code then it probably wouldn’t have been able to bridge the gap.

More prosaically, it’s been handy for snippets of unimportant stuff.

I wanted some random HTML to include in an illustration, and it took moments to get some that worked well and was ready-formatted.

I’ve left our own experimental bot running, because we’re a multilingual household, and I added the ability for it to watch for national flags as reactions to human messages, and translate the message accordingly. It’s very good at that.

“Real” applications

None of that is moving the needle much, is it? So why have I bothered with a long post on the subject?

Well, if I’m honest, partly as a counter to some of the hype. But there are things that are handy.

For me, the value has been in simple, predictable but “fuzzy” applications, where generic knowledge can apply to a specific query.

As an example, one that’s been running for a little while in our own business:

In our bookkeeping, we use fairly standard account codes for spending and expenses, but the exact set are unique to us. It turns out that an OpenAI call is very effective at deciding which code applies.

The routine pulls together the available codes, with descriptions, tells the LLM to assume the persona of a UK bookkeeping assistant, and the format of response required, which is basically JSON. It then supplies two examples with responses, and a third which is the current expense to be categorised. All of this is structured in the form of a chat, with the initial instructions as “system” role messages, and the examples plus the real query as “user” and “assistant” exchanges.

For OpenAI, we can also adjust the “temperature” of the generated response, which is a measure of randomness or, as experienced by the user, creativity. So we set that very low, say 0.1.

When called as part of the input of new invoices, we get (so far) quite ideal spending categories applied.

Is it overkill?

It may well be, just for this. There are other approaches that could do much the same, probably.

But the interesting thing is how quickly adaptable the “Chat AI” system is, and how re-applicable. It doesn’t care what the categories are, or what for. The same structure could be re-purposed with almost no change to apply categories to anything. All that needs adjusting is the data to be fed to it (which in our case is fetched from the database records). And if the categories change … well, the lack of memory means it was all fresh to it every time anyway, so it’s at no disadvantage. There’s no retraining, or extra conditionals to add.

So the key here appears to be: sufficiently generic context (in this case UK bookkeeping conventions), specific data on the exact requirements (our categories and some examples), tightly specified response format, including the examples (our JSON schema, which feeds into the rest of the routine), and the ability to package all that in the form of a chat exchange.

As someone used to development, which is meant to be rigorous and logical, this all feels a bit like witchcraft. It’s more like incantation than programming. But it works, and with a lot less trouble than a bespoke solution.

If you have something that could do with a humanlike judgement routinely, those conditions above apply, and you can package it successfully … yes, I conclude that generic LLM calls are a useful way forward.

It’s also easier, frankly, if the inputs aren’t directly from a human, even if that does make it much more dull and invisible.

I, for one, am continuing to explore what’s possible beyond this simple and naive approach.

New ERP!

Someone will often then talk about a new ERP. Or, short of that, a full new re-implementation. But most often a new ERP.

At this point – stop.

Is the problem the ERP, or is it the way it’s set up? Unless you’ve let an old system gather dust without updating for years, the ERP itself is probably capable enough, and the problem is how you’re using it.

New ERP! Without any of the problems!

OK, maybe so. But a new implementation will force you to fix that, right?

Beneath the surface, this is often a big driver of ERP implementations. When there’s a new system to install, you have to fix all the things. FIX THEM ALL. Everybody loves the idea of having all the niggles fixed, and there will be no excuse.

ERP sales people know this well.

Think, though. You'll be fixing those problems and working out how to make a new system work for everything that is working, and getting everybody to learn new ways of doing everything, and new interfaces, all at the same time.

This is not just repairing the engines while the plane is flying, it's removing them entirely and replacing them.

Too often, once the project is under way, it's as much as the business can do just to get the new implementation done at all, and all those nice process fixes take a back seat. Everything is so new that people push for things to be done the old way wherever they can, even if those old ways were the problem in the first place. And the people doing the work are too exhausted to push back.

New ERP, with a mix, now, of old and new problems. Lovely.

So what's the alternative?

Here I assume you have Epicor ERP10 or Kinetic, because I know those are capable enough for most businesses.

If you have problems, there's almost certainly a mismatch between your business processes and how you're using the system. Often that dates back to a few key decisions taken when implementing that turn out to be drawbacks, and either you feel stuck with them or it hasn't occurred to anyone to question the original assumptions.

Before deciding what to do, visualise what a working system would do, and how. What would the business run like, say, two years from now, problem-free? What would that actually be like, and what are the key differences from now?

You might need experienced help with this, or you might not.

Now, if you were starting again with the ERP you have, could it do all that?

If the answer is yes, even with some expert work, then do consider making that happen.

Why, though?

No matter what the sales people tell you, a new ERP won't fulfil your new vision out of the box. It might be a bit closer, and it's worth getting independent expert advice (not from me, from someone who knows multiple ERP systems) on whether it might be close enough to be worth all the expense and trouble of changing.

In most cases, though, the work to configure it will be necessary in a new system, and can be done to the old system.

Not only do you save, keeping the old system, but by losing the time, effort and expense of changing even the basics, you free it up for changing actually what you want to change. This makes a serious difference.

It isn't as glamorous as a shiny new system, and don't underestimate how important that is as a draw. Shiny and new is attractive. It just isn't always rational.

You can have your vision with the ERP you have, probably. It will be hard work making the changes, and there is a right way and many wrong ways between now and that blissful future. You will probably need expert help, just less of it than for a whole new implementation.

OK, so how, then?

Well, this is long enough, so there will need to be a part two.

Whizzy and new.

If you’re already using ERP10, it might feel TOO new. There’s been a lot of fanfare about the whole new interface, new client, entirely fresh ways of interacting with the system.

And a lot of buzz about cloud.

Maybe you quite like your on-premise system, and all the tweaks you’ve made to it, and aren’t sure if you’ve quite got the time to go through a whole new way of doing everything?

I have good news.

As I write, in late 2021, I am working on several different Epicor installations between 10.1 and Kinetic 2021.2, and all the things that might involve more change than you’re ready for … they’re all optional.

Kinetic itself is a nice upgrade from ERP10, no more scary than a point upgrade and a lot less than some there have been.

You can keep using the existing client.

No retraining for a new interface, no finding that the customisations you’ve made don’t work or need re-doing (any more than for a normal upgrade, anyway). You can carry on as you are.

And, for those who are interested, the technical stuff underneath gets better and better. If you do like to customise, there are more and better ways to do it. I’ve enjoyed working with Kinetic, myself.

Kinetic is the way things are going, and it is possible to take it gently. If you do upgrade, it seems possible to dip your toes in to what’s new - anything new may appear in a new form, but that’s OK, because it’s new anyway. What you and your users already know can stay as it is until you’re ready.

It’s up to Epicor to make it worth your while to take the plunge into all that’s new, and in the case of the interface they haven’t really tempted me yet, I confess. But that’s OK. It’s there waiting, and I for one would sooner not get too far behind.

If you’re using Epicor, you have the System Agent to do that for built-in process and tasks, and you can set reports to happen at certain times.

What if it’s something completely custom?

Or maybe it should happen when triggered, but after a delay?

Ah …

There has been a module specially for that, but you don’t need it.

(You can also use Service Connect, if you have that, but if you do, you probably know that).

Epicor is very good about allowing even the deeper guts of the system to be used in BPMs, so that means you can automate the scheduling too.

When something needs to happen, but not quite yet, you can create or alter a schedule instead of doing the task directly. A second BPM set can then fire when the schedule changes to do the actual work.

Obviously these schedule-related BPMs need constructing with great care, because they will fire for every schedule change of every kind. They need conditions which exit as soon as possible when they are not required.

There are a few ways this can be useful.

We use this for some tricky integration components, for example, where data needs to be synced to an external system. In some cases we need to be sure that Epicor has finished complex updates before the sync happens, so it’s wise to delay, or the sync process would interrupt further triggers that need to complete so the user can finish their task. In others, a constant mass of data would swamp the integration system, so updates are added to a queue until the last is complete and then all sent at once.

That last case is particularly interesting, because it provides a neat way to handle things that happen in batches (invoice posting, for example). Each event moves the schedule on a little further, so the final scheduled task automatically happens only when there’s a break for it.

Warning

As I’ve already hinted above, DO NOT APPLY THIS TECHNIQUE RASHLY.

If you don’t know what you’re doing, particularly with data directives, leave this method well alone, because you could gum up your Epicor system and slow it to a crawl. But it’s very powerful and solves otherwise insoluble problems, done with care and precision.

The “correct” way to set up Epicor CRM is wrong.

I’m pretty sure it’s the biggest reason why the CRM module doesn’t get a lot of love, even from committed Epicor users.

Epicor CRM has everything you need.

OK, it’s not ideal that the functionality is spread over a lot of screens, but a few dashboards can fix that. It’s actually very powerful, and the functions you need in a CRM are almost certainly there.

Just as long as you don’t use Quote/Opportunity for most of it.

The thing about CRM is that friction kills it.

Nobody WANTS to enter data into CRM, no matter how much they want that data to be there when they look for it, and nobody wants to be spending time on admin when they’re looking after customers or hunting new ones.

The answer, in the Epicor system, is the wonderful multi-tool that is the HelpDesk Case.

To create and save a Case, you only need to enter a summary of what it’s about, with a selected Workflow.

The end.

If that’s all you have time for, it works. You can add the customer, the contact, a product, a logged call, a task, whatever, later when you DO have time.

You can use the same Task Sets as for Opportunities, you can link anything you like.

If you’re used to using a Quote as an Opportunity then it’ll be a revelation how quick and easy it is. Epicor’s Quote system is ludicrously powerful, but it’s overkill for a simple enquiry.

Oh, and if you’re using a Case instead, once you get to the point of needing to Quote, you can create and link a Quote from the Case anyway.

If you have Epicor, and you’re considering CRMs, take another look at the built-in module with this in mind, and it suddenly becomes a real option. Which is great, because it keeps you in the system you’re already using and everyone knows.

I can understand that.

Service Connect has always been a bit of a dark art. People who know how to get the best out of it are few and far between, and that's a problem for a tool that might act as a vital junction among your systems.

And this kind of tool IS increasingly vital.

Everything needs to talk to everything else these days, and things like Service Connect, which enable that communication, are only going to become more and more crucial.

I'm going to go out on a limb here, though, and say that if you already have Service Connect running, and it's doing what you want, you should be happy with that for now. There is nothing wrong with it. It's as good as it ever was, and there's no sign that Epicor is going to pull the plug on it any time soon.

Plus, most of the alternatives gleaming all shiny in vendors' sales packages - they're going to cost you, one way or another. You need a real reason to switch, not just a sense that the dust might be building up on what you have.

So what IS a reason to switch?

If you're needing to do something entirely new, and you'd need to find someone to create complex new workflows in Service Connect (assuming you can't do them in-house), you should weigh the costs of moving across to a new solution. Not forgetting to count the expense and hassle of changing what's already working.

And if you don't already have Service Connect, I'd be hesitant to recommend it as a new installation at this point.

That is hassle. Is there a halfway house?

Glad you asked.

Service Connect traditionally calls directly on Epicor ERP via the client libraries, which is a very intimate kind of connection.

But it also works quite well for REST calls. And Epicor ERP is now all in on REST.

So you can kill two birds with one stone here.

You can move the logic of what you want to do into the ERP system itself, and expose simplified calls as Epicor Functions available via REST. That future-proofs your functionality, and widens the pool of people who can work on it, even if there's a lot of bespoke.

You can then make the REST calls from Service Connect, and the workflows should be as simple as humanly possible.

Not only does that remove most of the problems associated with using Service Connect in the first place (reliance on something that is difficult to support and few people understand well), it becomes relatively trivial to replace with an alternative tool at any time.

If you keep all Epicor ERP logic within Epicor ERP, Service Connect - or any replacement - has no need for tight coupling, and whoever is managing that part of the system needs no direct knowledge of the ERP's workings.

TL:DR - REST is now the way to go.

But the key thing to realise is that you can go REST-based now, and move on from Service Connect later as and when it makes sense.

And at META eight we're experienced with both Service Connect and REST, so if you want even-handed advice feel free to talk.

But it’s still core to most installations at this point, and may remain so for a while. Not only because there is so much familiarity with it, but because it’s extremely customisable, and the newer systems have a long way to go to catch up.

For me, there have been two keys to moving beyond simple customisations in the Epicor client. Between them they allow bespoke screens that can do practically anything.

1. Epicor’s “Dynamic Query” business object.
2. Using classes within the customisation code.

Dynamic Query is the way to call on Epicor’s BAQs (Business Activity Queries, or user-created ways of pulling together Epicor data). That means one object gives you access to exactly the data you choose, and you can create parameters to make it completely dynamic.

The benefit of adding classes to a customisation is more subtle. They allow what you create to be more modular. Declare a class, create an object of that class, and all the functionality you need is repeatable without cluttering the core code Script.

Combining the two means you can bring in what data you like and make it work together without getting tangled up.

This works so well that we’ve created two standard class families that we re-use all the time, and for the first time we’re sharing them publicly.

They’ll be appearing on GitHub - the first elements are there already as M8DynQuery, and more detail will be joining them.

Look out for more posts around how M8DynQuery works and what you can do with it.

Databases are my friends, too, I admit. And automation, scripting and all that - well, what kind of ERP expert would I be if they weren’t bread and butter?

But websites mostly don’t need to be clever.

Fast, clean and informative - yes.

So we’ve gone static here.

What IS a static website?

Back in the old days of the web, everything was fixed. When you called up a page in your browser, that page existed somewhere on a server, just as if you’d opened a Word document.

These days, mostly the page is created on the fly as you need it depending what you’ve asked for, who you are and what some system thinks you want or might be persuaded by.

Which is a) overkill for most of us, and b) quite inefficient.

Because it’s inefficient, in fact, the best systems go to some trouble to find out what you’re most likely to want and store it ahead of time.

A static website cuts out all that, and goes back to simply storing all the pages you might want.

The cleverness is in the system that generates it in the first place. (This website uses one called Hugo). Once it’s all out there, it’s as simple as it can be.

It should be fast. Is it?

It would be nice to know how you find it.

And if there are any problems, down to spelling mistakes. Let us know.

This is not something that comes up a lot, but it can. If you deal with customers who have strict secrecy requirements, then communications, enquiries, quotes and so on might need to be restricted to approved staff. You may work with NDAs (non-disclosure agreements) or have other confidentiality arrangements.

And Epicor, since it works well on-premise, is a good ERP for the privacy-conscious.

But while security in the ERP system is excellent, and has become better and better with successive recent releases, it’s focused on access to different parts of the system. Natively, you can’t easily allow a user to see some of one type of record but not others.

Which is why it’s great news that Epicor is so customisable.

Once there are clear rules for allowing access (which you as the business would know best) you can intervene as the records are fetched.

For each type of record that needs restricting, there are typically three methods on the business object that return the core data: GetByID, GetList and GetRows.

For most of these, across all the system, you can add a Pre-Processing method directive which adjusts the “where” clause for the requested data in the background. The “where clause” is the description the system sends to itself of the exact records needed - for example all the open sales orders for a particular customer. If it’s adjusted according to the agreed rules, then bingo! The user sees only the records they’re allowed to see.

It isn’t intrusive - there’s no “access denied” or anything - just the filtered version served up as normal.

And what’s particularly good about this is that it doesn’t matter where in the main interface the user is, because those methods supply the data for all of it (with a few caveats to be aware of).

No special versions of forms or screens, no running to catch up if something changes and there are new ways of accessing the information. It just works in the background, whatever the interface.

That’s because there are no cookies.

No tracking.

No analytics.

If you want anything, you know where we are, because here you are on our website. There’s a contact form and even a phone number.

We aren’t going to stalk you across the web, and we won’t send you anything unless you sign up for it.

See you when we do.

This is a subject to be wary of, because there are a lot of people ready to tell you things that aren’t strictly true.

Epicor ERP10 / Kinetic is great, and very flexible. But of course there are things it can’t do, and there will always be specialised services that work much better for particular things.

If you have something like that, and want other software to talk to your Epicor system, you may get one of two answers when you ask about connecting the two:

1. It can’t be done, because there is no existing solution
2. It’s very easy, because Epicor provide REST API access so we can just use that

The truth is somewhere between the two, usually.

As long as your Epicor system is reasonably current (10.2.500 onwards), integrating in both directions is quite straightforward - with knowledge of Epicor. For older systems, outward integration is straightforward, but complete solutions usually need Epicor’s Service Connect middleware or an equivalent.

So how to integrate with Epicor?

The key is knowing what you need Epicor to do, and how Epicor does it.

The APIs are quite low-level. You can’t simply, for example, send sales order data to a “create sales order” point. The Epicor system will want a sequence of calls, in the right order, with the right data each time.

That means anything is possible, but you’ll get there faster if you have someone in your corner who knows how to work with Epicor.

And - warning - this applies even to “no code” or “low code” tools. They may connect to Epicor, but you’ll still need to know what to do with that connection. An integration solution doesn’t do all the work for you.

Summary?

Yes, you can integrate beautifully with Epicor, or connect other software to it. It’s just a whole lot faster and smoother doing it if you’ve done it before or involve someone who has.