People in the ERP business, I’ve noticed, tend to come in two types.

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.

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.