Comment by brettv2
1 year ago
> 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.
> 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.
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:
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, ... :)
> 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.
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...
4 replies →
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.
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
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?
2 replies →
> 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.
"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.
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.
6 replies →
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.
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.
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.