[brettv2]

> 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.

[mamcx]

> 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!

[gscott]

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.

[RowanH]

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.

[mamcx]

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, ... :)

[hawk_]

> 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?

[hef19898]

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.

[laser]

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?

[SteveNuts]

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.

[arnorhs]

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

[briandear]

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.

[logkeeper]

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.

[MichaelZuo]

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

[nslindtner]

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 ?

[mamcx]

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!)

[sam0x17]

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

[mcsoft]

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.

[fakedang]

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.

[kfk]

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?

[5cott0]

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

[ibash]

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

[samsolomon]

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

[sesm]

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

[noutella]

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

[hef19898]

That's not ERP so.