←back to thread

YC: Requests for Startups

(www.ycombinator.com)
514 points sarimkx | 6 comments | 14 Feb 24 16:31 UTC | HN request time: 0s | source | bottom
Show context
brettv2 ◴[14 Feb 24 15:54 UTC] No.39371339[source]▶
> 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.

replies(15): >>39371417 #>>39371513 #>>39371559 #>>39373523 #>>39373559 #>>39373655 #>>39373844 #>>39373923 #>>39374114 #>>39375168 #>>39375430 #>>39375543 #>>39377087 #>>39382481 #>>39383460 #
hef19898 ◴[14 Feb 24 19:12 UTC] No.39373844[source]▶
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.

replies(1): >>39375192 #
1. laser ◴[14 Feb 24 20:54 UTC] No.39375192[source]▶
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?
replies(1): >>39375396 #
2. hef19898 ◴[14 Feb 24 21:08 UTC] No.39375396[source]▶
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...
replies(1): >>39375803 #
3. arach ◴[14 Feb 24 21:36 UTC] No.39375803[source]▶
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

replies(1): >>39376107 #
4. hef19898 ◴[14 Feb 24 21:57 UTC] No.39376107{3}[source]▶
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.

replies(1): >>39376239 #
5. arach ◴[14 Feb 24 22:07 UTC] No.39376239{4}[source]▶
it's complicated because it's complicated and the pay is good sounds like good white collar jobs about to get automated away
replies(1): >>39376273 #
6. hef19898 ◴[14 Feb 24 22:09 UTC] No.39376273{5}[source]▶
Serious question, what is your experience with ERP systems so far?