Hacker News Reader

Comment by brettv2 | Hacker News Reader

> NEW ENTERPRISE RESOURCE PLANNING SOFTWARE

Very curious if anyone knows how to pull this off. There's so much value to be unlocked but it's just impossible to break through.

I've personally met three very talented founders that tried and failed (one was accepted to YC as a mid-market ERP and successfully pivoted into an application tracking system) and failed very quickly.

I'm guessing an important feature would be an integration system that maps data from the current ERP seamlessly into the new ERP. And that assumes you can even get through the enterprise sales process to even get the company to migrate.

View on HN

> Very curious if anyone knows how to pull this off.

I work in this space (small/mid-size).

The good news is that there are several "obvious" ways to pull this off because an ERP is the culmination of everything a company needs and does. So almost anything you can imagine on the software is part of it.

The bad news, and the reason everyone wants a solution, is that is truly a big space, and then you need E.V.E.R.Y.T.H.I.N.G.

---

My take is to start from the bottom, and build a much better version of Access/FoxPro (https://tablam.org).

Any medium/big ERP end being a specialized computing platform that needs:

- A programming language

- A database engine

- An orchestration engine

- ELT engine

- Auth

- UI/Report builders

And to be clear: NONE of the "programming language", "database engine", etc are a good fit today.

NONE.

This is the big thing, This is the reason (from a tech POW only) that most attempts fail.

This is the secret of why Cobol rule(d): Is all of this! but is too old! (also, this is why SQL still is best: Is almost this).

---

So, to pull this off, you need a team that knows what is "missing" from our current tools, makes a well-integrated package, and adds a "user-friendly" interface in a way that is palatable for the kind of user that uses excel (powerfully).

Is not that impossible. FoxPro was the best example of this kind of integrated solution.

P.D: This is my life's dream, to make this truth!

I spent 8 years buidling and running a crm system as a solo project. (https://web.archive.org/web/20080706045541/http://officezill...). I agree without a programming language and database for users to build their own stuff in like Salesforce does any groupware/crm is doomed.

But I think of the YC requirement more like build a Zapier and make your crm all an API. Use some sort of AI or business logic for users to glue it together.

But at the end of the day you still would need to build out an internal programming language as well because it still would not be enough without it.

The problems with ERP is (1) in order to be a big player you have to cater for so many use cases it starts becoming a glorified development tool without any room for providing actual ROI to the vertical that wants to buy it. (2) it's very, very easy to fall into the trap of saying "well, process x is really no different in industry y, we can adapt the ERP system". In reality there's so many nuances that the platform becomes compromise.

Vertical specific software provides so much more value as you can build things unencumbered by the engine/data structures/way things work.

I've found our niche - ERP's would be hopelessly expensive so save for top tier OE companies no one uses it. In weeks we can develop and roll out features & functionality that our clients just lap up that you would never in a million years build into an ERP platform, but is intrinsic to the delivery of our clients products.

It was inconceivable to me 2 years ago, but now I've had very real discussions with some companies where they're looking at our software going "wow... you're going to give mid tier players better functionality that we could only dream of from our ERP systems.."

Basically ERP platforms are "jack of all trades, master of none".

In my former life we did vertical specific software for the window and door industry. Every time we heard from a prospect "oh we're looking at __some ERP platform__ to do configuration of W&D", we'd immediately list dozens of reasons why they would fail, and fail hard.. countless untold money to consulting teams has been burned learning those lessons.

> In weeks we can develop and roll out features & functionality that our clients just lap up that you would never in a million years build into an ERP platform

Interesting. Just to make sure I understood this correctly, are you taking of a purpose built app/software for each such 'request' as opposed to this being some 'module'/'add-on' in an ERP suite?

Yeah so in an ERP platform, you (well the client) needs to pay for a feature they want to be built ontop of the platform. It may have additional tables/data structures added into the ERP system or outside of it. Sure an ERP might have say an "Field Service Module" add-on you can get. But if you're a Spa Pool shop, there might be a whole bunch of things you do spa pool specific, eg taking water chemistry measurements. With an ERP system to add say a 'chemistry tracker add-on', you're very unlikely to find one off the shelf, so you need to customise the ERP system to do it. By the end of having an ERP system that works for your Spa Pool Empire you've blown $100'000's to $millions.

The alternative is some scrappy startup does a SaaS platform for Spa Pool shops and builds the features natively. Not being hamstrung by the ERP platform, so no compromises - no UI's that look like an ugly duckling. And of course they learn every new spa pool shop that comes onboard, adapts and improves.

Eventually the SaaS software startup will become the Spa Pool system of choice, and will come up against the ERP platforms in sales pitches.

One will be ready to go for a Spa Pool shop, the other will have a team of consultants wanting to do requirements gathering....

That's the problem with ERPs, when a vertical/niche has got dedicated software, the ERPs almost always look inferior*

* Upto a certain business size/throughput/specialised requirements, then Mega Spa Pool corp is okay paying millions to have their own ERP team.

Yeah, this is the way for the small/mid tier (this is also how I do for https://www.bestsellerapp.net)

What make this complicated is that each company turns into a different project. So is like have several branches:

    ERP
       /CompanyA
       /CompanyB

This is high maintenance the more successful you are (and puts a serious barrier to adapting to certain customers).

It gets to a point where after a certain # of customers you can't grow, and now is where you think about making your own DB, programming language, ... :)

You already cannot map data automatically from one SAP instance to another, so forget auto migration. What usually happebs is, to keep the legacy system around for auditing purposes, and the live business happens in the new one. With cut-off dates per function and or department. With manually developed interfaces, and all the crap that comes with those, during the migartion period.

An nothing of this has anything to do with SAP, and everything with ERPs and the messy reality of businesses.

Why is it not entering the realm of possibility for the migration system to function not at an API layer but at the levels of pixels and OCR and RPA to click through every possible interface within the ERP to export and structure the legacy data to complete a total migration? Like humans copying over the data manually?

Because the migration has to be auditable. And the data fields between the systems / databases mapped against business processes, on both systems. If you find a solution to automate that, cudos...

would it be fair to suggest an automated migration solution (therefore less manual) might be more auditable than human driven?

You'd probably start with a human in the loop solution but mapping should be a solvable problem

No, from my experience it wouldn't be fair to say that.

There is a reason why migration projects are yearlong, multi million projects. Go through one, ideally multiple, of those first before looking at automating any of that. Added benefit, jobs at those projects pay incredibly well for the functional consultants involved. And when, when not if, automation doesn't work out, you still don't have to worry about a job ever again.

it's complicated because it's complicated and the pay is good sounds like good white collar jobs about to get automated away

Serious question, what is your experience with ERP systems so far?

Step one is to make sure it's auditable.

Every auditor on the planet is intimately familiar with how Oracle EBS and SAP do certain things.

If you don't have that trust built up, a customer simply won't want to take the risk and additional headache and overhead passing an audit will take.

Sounds like there is the opportunity. An ERP that can eliminate the need for auditors. Then it won’t matter what the auditors think. Auditing isn’t some black magic. It’s a set of rules. Rules a machine can follow.

A machine controlled by the audited company. Audits are there to minimize the risk of companies cooking the books.

You never went through an audit, did you?

> A machine controlled by the audited company. Audits are there to minimize the risk of companies cooking the books

Sounds like the pitch Fujitsu made to the Post Office for Horizon. That worked out so well!

Rounding errors, simple rounding errors. Nothing to see here.

"Auditing isn’t some black magic. It’s a set of rules"

This is not true. Auditing is half assurance and half insurance. It has nothing to do with the actual results of a bunch of rules and checks.

> Sounds like there is the opportunity. An ERP that can eliminate the need for auditors.

You cannot eliminate the need for auditors - the need is for someone to go through the system and make sure that no one is cooking the books.

Hence, an independent third party does the audit.

This makes me wonder. I wonder if the real opportunity is in solutions that help auditors in one way or the other.

If the auditors are sensitive to which systems they are familiar with, it would perhaps be beneficial to the auditors to be able to understand other systems.

I'm sure there are companies that are servicing auditors, creating UiPath flows or whatever for a bunch of auditors. So there's probably already a ton of very specific solutions out there, for auditing various systems.

At least it sounds like a more solvable problem than yet another ERP

Hi. I'm working on Logkeeper which is an all in one business management platform.

I don't think it will be possible to compete directly with the big players. However, having spoken to a few potential customers, it seems my software can help businesses that are small today but will scale up tomorrow. If I can prove that my software can indeed scale up with them, I will have a good opportunity to tackle the enterprise side eventually. Right now though, I'm just focused on getting the product to a level that helps these smaller folks out. I have been working on it during evenings, and this is my first week moving forward focusing on it full time. Let's see where it goes. I'm really early stage, super fresh to business, but I'm experienced as a swe and consider myself a closer. Cheers!

If you want to know a little about my background, I've worked on massive (many, many millions of dollars) ERP projects from the business side. I've also been a platform engineer/lead on a saas that IPO'd a few years ago. I've seen it from both sides, and I believe that I have an idea of what is missing when it comes to business software in general.

What is the current state as of time of writing? Are you willing to talk about it, warts and all?

I have allways wondered why there isn't a "headless" erp-system.

I have worked with cms-systems. And in this world it is accepted, you need different frontends for different tasks. Therefore a world of systems - calling themselve headless - support only the backend part of cms management. Worked with Strapi that support this kind of thinking.

How come something similar doesn't exist in the ERP world ?

One major reason is that both developers/customers who ask for it think in UI first, all the time.

Most developers I know are at the far-end of development practices (one of the ERPs I integrate has tables like `F0001, F0002, ...` and fields `F00001, F00002`), and this ERPs then uses old tools like Cobol, Fox, (Old) Delphi, (OLD) VB where it has a better UI history.

And it causes to be very hard to build an API (you can't image how much torture is when an ERP vendor says "we have an API!" instead of using plain text or direct SQL)

For this, you need people that know how to do good APIs. And the good API for an ERP is NOT Rest, GraphQL, JSON, ... (ideally, you need a DB!)

Well the UI-first thinking makes more sense, since in most cases you are solving process-problems, which involves "what does who do when?"

It's hard to communicate a process through a REST API. Sure you could document it incredibly well, maybe even have every part of your ui represented by an API endpoint, but ultimately, due to the number of customizations involved with each ERP view, you'd end up with some sort of bastard, which was never quite the same as the real deal.

another key thing is you need SOC 2 or ISO right out of the gate. We actually had to do that at Arist when they were seed stage because all the customers are literally FANG and fortune 500s which require such certifications to even do business with a vendor

It's the kind of software where early venture capital funding can be poisonous rather than helpful. Choosing the right abstractions to build a solid, flexible platform requires a lot of user feedback. You don't get the latter unless you have *paying* customers who have switched their critical processes to your product for a while. You need to build, sell, implement, and provide several upgrades. We bootstrapped a low-code BPM platform (pyrus.com) and were lucky to break even in several years. VCs push you to grow, while premature scaling could be harmful in the long term. It takes time before your platform is mature enough to serve inherently different use cases.

ERP is a tough space to compete in, as you're fighting against SAP, Oracle, Microsoft, etc. I would say that ERP, CRM and Enterprise payments solutions are the few spaces that firms should not compete in - in a few years, these companies will be akin to COBOL for airlines.

Not a direct answer, but I am targeting data marts from ERPs and other Enterprise applications like CRMs. I think data marts (data warehouses) are very valuable but they are too expensive and hard to build, so an AI that could generate the sql for the marts directly from the apps could be very valuable. What do you think?

ERP market is way too complex and oversaturated for pretty much every vertical imaginable

I’ve met a few people who’ve been on the buyer side of an erp migration. It’s a multi million dollar affair that takes years.

Two approaches I can think of:

1. Target mid market or smaller and grow with customers (will be slow)

2. Take a front-door-wrapper approach

Or 3. Target a small slice of ERP/CRM tooling and gradually evolve into something more fully-featured.

The problem is ERP needs to be incredibly tightly integrated into the whole business from end-to-end.

You can't only offer raw materials tracking, but not accounting and shipping. There's just not a lot of value to the business unless you have everything coupled.

The MVP for an ERP is essentially, a fully featured and battle-tested system which is very expensive and time consuming to build before it's profitable.

Most companies that I know that did it right forked something that was already mostly working, built it in house for a client and then spun it off, or yeah, have billions of dollars and still make a fairly half assed solution.

That's strictly true for standard definitions of ERP, but it's a rare enterprise that doesn't already have adjacent software they've licensed to specifically support parts of their business. This could be freight & logistics, or warehouse management/inventory, or QA/Test, or RMA, or whatever. Convincing someone to move away from Oracle or SAP is a nonstarter for a startup. It worked several years ago for Netsuite, which advertised itself as the first "cloud native ERP" and was widely lauded for being so much more easily customizable than Oracle (so Oracle bought them in 2016).

I don't think starting a new ERP company from scratch makes sense for anyone. The best you would likely do is to become either a minor player (just look at the array of CRMs that aren't Salesforce), tailored to a very specific market niche, or an "ERP adjacent" platform of some kind. That last bit is the obvious play. The bread & butter of Enterprise Applications IT departments around the world is to build custom stuff that inherits data from ERPs or feeds data into ERPs and similar mission critical business platforms. Speaking as a guy who ran one of these departments in an F250 for about ten years, most of what they build is pretty crappy.

> The problem is ERP needs to be incredibly tightly integrated into the whole business from end-to-end.

So you target firms that are not yet at the scale where they likely have or need ERP with something that does something they do need that would be integrated into an ERP when they get to that scale and build out from there.

No one is buying an ERP from a firm that doesn't either already have a deep relationship with the buyer or a track record in the ERP space or a track record in an ERP-adjacent space, and more than one of those is desirable, so be in the position that when you start trying to sell an ERP you have at least the last plus a stable of firms for which you also have the first.

The MVP for ERP is literally excel.

Notice that excel is a huge product.

Ah ok. I'm an interested in this as a topic and would like to take a stab at this as I think it's an almost impossible project. I would like to caveat any opinion first by saying these: I have a great deal of experience customizing and creating little bits of bespoke functionality for various ERP systems (SAP obviously but also some of the smaller ones aimed at niche markets eg construction). I also have similar experience with similarly complicated and sprawling PLM systems. I've spent basically my entire software career around ERP and PLM systems and systems that break out pieces of ERP functionality and try to often do it elsewhere (usually badly), and then usually have to somehow bring everything back into an ERP system anyway, either manually or with at least some level of (but rarely complete) automation.

I am a CS graduate from a 'famous' UK university (UCL). I'm also a qualified CAD engineer, project manager within agile (DSDM agile etc)...ITIL qualified etc. i.e I've spent a lot of time across these kinds of many tentacled systems that really do reach across the entirety of any large business. I've worked with these systems from FTSE 50 businesses to small 50 person manufacturing startups.

I've also been involved in the migration between PLM systems (horrible from a data perspective - all those CAD files etc) and also ERP systems (horrible but largely just the mapping between two different Entity Relationship Diagrams almost incomprehensible to any living human in terms of complexity).

It would be an incredibly ambitious undertaking to compete with one of the major players in either of these spaces. It is not something you could really even do at the scale of a start-up the likes of which YC and the media understand as 'start-up'. You would need so many not just 'early stage' founders with wildly different skillsets, you would need effectively an entire large manufacturing business, from end to end, in terms of personnel because your 'domain expert' essentially includes 'every business function you can imagine'. That's before you could even begin to think about software. It's a fascinating idea but think about it - procurement/purchasing, warehousing and logistics, engineering and design, sales and marketing, finance (very important here), HR, operations, R&D, Q&A...and these are just the ones I can think of that I have come across in my dealings with these systems. They really do touch every department.

The length of time to market would also be such that this kind of project would not really be appropriate to describe as a 'start up'. You'd essentially be creating a 'Unicorn Killer' and that unicorn killer would need insane resources to even have a chance at market success. The number and requirement for specialist migration tools into your new system from existing clients would be a 'massive' undertaking also.

It's such a bold idea but I think to describe an undertaking of that size 'start-up' would be to completely stretch the meaning of the term 'start-up' so far beyond its usage that the term would lose all meaning.

The days for this to work where back when SAP was young and ERPs the latest dosruptive tech. In order to repeat that, one has to wait for a new technology to replace ERP as a whole, developing a new ERP simply doesn't cut it.

I could see where a startup can solve one of these slices in SaaS form with the intent that it could be also sold as installable via containers on premise or in a private cloud for a customer.

Then do the same for another slice, offer it to existing customers and make the completed slices work well together. Then another slice.

And along the way there could be profit to fund the next slice, as well as existing customers you can tap into to solve their problems. It would be simpler to niche down vs. the SAP/Oracle path of ERP-fits-all.

Start with a niche market and grow from there. For example, ERP for tech startups, so YC can recommend you to their companies.

Https://pigment.com is an impressive example of a startup managing to address this market successfully.

That's not ERP so.

Reply on news.ycombinator.com