Let me say from the outset that I agree. So this criticism really is friendly criticism. Also: I have little hope, though I want to hope. So...
1) The concept of ERP is flawed.
ERPs are basically trying to solve the problem of documentation. Remember, ERPs were developed by IT. And they're what happen when IT people try to solve a problem using IT tools and IT methodologies. Now, is there some good there? Yes. Steve the Secretary can't quit and take his 20 years of experience out the door with him. "Where do I find <x>?"is never[1] a question post-ERP, because the process is well-defined.
Think of it this way. You already have a business (program). But you have a problem in that the founders are getting old, or workers are getting old, or things aren't being done consistently (no commenting). So with this massive program, you're going to cull through the processes people are already doing (source code), and evaluate them (optimize) and then implement a consistent approach (document the new code).
Guess what? That's hard to do with 20,000 lines of code. Now do it with a thousand employees. Oh, and make sure they remember that "one person" they call once a year to make sure your biggest customer gets their fruit basket every Christmas.[2]
"Well, all this sounds like a good idea!" you're saying? Sure, in a sense. But here's the flaw: just like good code, a good organization needs documentation from the very beginning. And that's my first criticism: don't get into the business of going back and documenting things that should have been done. Get involved in being involved from the very beginning. Of course, that's harder to "sell" -- small businesses have smaller ERP needs because there's less of an enterprise. So you'll make less profit. What makes me hope against hope: your solution could grow as the organization grows.
2) Big business is better than small business
There's a reason most ERP customers are big businesses: they have a lot to lose with knowledge leak.
But that's not the real reason. The real reason is that they're most able to benefit from the ERP while minimizing the cost of implementing the ERP. How do I know this? Big businesses usually get big because they have good business practices. And they're good at communicating those practices to employees. That is, they have good procedures and good documentation -IN THE FIRST PLACE-. So the process of encoding that is, while not without incident, not as hard as it could be. A small business that stays small because of the high training costs they incur every time someone moves on, or who doesn't follow procedure well so is unreliable, or what have you--THEY'RE the ones that have the most to -gain- from an ERP, but they're also the ones least able to bear the costs of documentation. If you're following the analogy, large enterprises already have some documentation, but have some poorly-documented interactions or classes. On the other hand, many small businesses have far LESS documentation - either because they don't need it ("Only 100 people, we can communicate it!) or they're just bad at it.
All that to say: the people you're marketing to are least able to meet the needs of the requirements / planning phase. That's a problem. I think there are solutions, but your post makes it sound like they're (smaller enterprises) are the EASIER customer, and I don't think that's necessarily (or even often) true.
3) ERPs are not modular
ERPs are almost the perfect example of the corporation existing to protect its own existence. "We've got a good thing here," says someone high up, "Let's keep it that way." ERPs -sell- themselves as being modular and adaptable and nimble. "Nimble" doesn't need a multi-million dollar budget, a hoard of consultants, and two years.
Say your HR department figures out a method of processing applications that increases processing speed by 10% with no degradation in quality. Without an ERP, the head of HR (maybe) checks with their VP and then tells everyone below them to change, and that's that. Good luck making that change post-ERP.
And this is the downside to the upside I mentioned above. Steve the Secretary can't quit, but Gillian the Genius can't get hired and have a brilliant insight that rapidly streamlines processes. (Which, I suppose if you really think about it, is what enables ycombinator: large organizations with non-malleable standards need to outsource innovation. Lucky us!)
The plus side: although the cost of inter-departmental interaction change goes up, the intra-departmental change is (comparatively) easier.
I think your system could benefit in modularity, especially if the ERP were "in the hands" of the people. But that, of course, increases risks.
The bottom line: if you build for modularity (really build for it, not in the "The salesperson told me it was modular" sense) from the beginning, it would be amazing. But you have to really build for it. And I know you get that, but I don't think I can say "really" enough times here.
The BEST of luck!
[1] If you listen to marketing. There are still problems with finding things post-implementation, but I will concede these types of problems are significantly reduced. The -real- loss now is, "How do I get <x> done when the ERP doesn't want to let me?" - and THAT answer is far more valuable, in my opinion, and far less often documented.
1) I don't think so. The real win is for an ERP is not processes, it is reporting. Being able to examine every aspect of the business in ONE place in a real-time fashion is an amazingly huge boon for businesses. Businesses succeed not because of good processes, but because of constant improvement. You can't improve if you don't know what to improve. A good ERP implementation will solve this with good reports.
2) For a startup, small businesses might actually be better. They might still be able to spend a decent chunk of change (.25-1M) on an ERP system, but have much lower requirements making an easier implementation that is less likely to fail.
3) ERPs aren't really modular, that is true. I'm not sure there is a win to a real "modular" ERP system. The who idea behind an ERP is that everything in a business is connected, so the systems should be connected too. Sales people are connected to orders are connected to finished goods are connected to build processes are connected to inventory are connected to purchase orders. Removing one "module" in that chain defeats the purpose of the ERP.
1) While that's nice in theory, the dashboard data has to come from somewhere. And it comes from the processes people go through. Combining the multiple application interfaces into one isn't merely a process of collecting data: it's also collecting processes. If all you had to do was collect data, ERPs would just sit at the junctions of your current data interconnects and feed all the data upwards. But that's not what happens.
2) I agree that smaller is better. But smaller isn't better when it comes to being able to set up requirements.
3) And it shouldn't. I should be able to say, "We're now doing A B C 4 E instead of A B C D E" and not have that change (assuming it's low enough) initiate a 4 week process of review before it ever has a chance of "going live". That -keeps- people from making the suggestions that evolve an organization.
1) The concept of ERP is flawed.
ERPs are basically trying to solve the problem of documentation. Remember, ERPs were developed by IT. And they're what happen when IT people try to solve a problem using IT tools and IT methodologies. Now, is there some good there? Yes. Steve the Secretary can't quit and take his 20 years of experience out the door with him. "Where do I find <x>?"is never[1] a question post-ERP, because the process is well-defined.
Think of it this way. You already have a business (program). But you have a problem in that the founders are getting old, or workers are getting old, or things aren't being done consistently (no commenting). So with this massive program, you're going to cull through the processes people are already doing (source code), and evaluate them (optimize) and then implement a consistent approach (document the new code).
Guess what? That's hard to do with 20,000 lines of code. Now do it with a thousand employees. Oh, and make sure they remember that "one person" they call once a year to make sure your biggest customer gets their fruit basket every Christmas.[2]
"Well, all this sounds like a good idea!" you're saying? Sure, in a sense. But here's the flaw: just like good code, a good organization needs documentation from the very beginning. And that's my first criticism: don't get into the business of going back and documenting things that should have been done. Get involved in being involved from the very beginning. Of course, that's harder to "sell" -- small businesses have smaller ERP needs because there's less of an enterprise. So you'll make less profit. What makes me hope against hope: your solution could grow as the organization grows.
2) Big business is better than small business
There's a reason most ERP customers are big businesses: they have a lot to lose with knowledge leak.
But that's not the real reason. The real reason is that they're most able to benefit from the ERP while minimizing the cost of implementing the ERP. How do I know this? Big businesses usually get big because they have good business practices. And they're good at communicating those practices to employees. That is, they have good procedures and good documentation -IN THE FIRST PLACE-. So the process of encoding that is, while not without incident, not as hard as it could be. A small business that stays small because of the high training costs they incur every time someone moves on, or who doesn't follow procedure well so is unreliable, or what have you--THEY'RE the ones that have the most to -gain- from an ERP, but they're also the ones least able to bear the costs of documentation. If you're following the analogy, large enterprises already have some documentation, but have some poorly-documented interactions or classes. On the other hand, many small businesses have far LESS documentation - either because they don't need it ("Only 100 people, we can communicate it!) or they're just bad at it.
All that to say: the people you're marketing to are least able to meet the needs of the requirements / planning phase. That's a problem. I think there are solutions, but your post makes it sound like they're (smaller enterprises) are the EASIER customer, and I don't think that's necessarily (or even often) true.
3) ERPs are not modular
ERPs are almost the perfect example of the corporation existing to protect its own existence. "We've got a good thing here," says someone high up, "Let's keep it that way." ERPs -sell- themselves as being modular and adaptable and nimble. "Nimble" doesn't need a multi-million dollar budget, a hoard of consultants, and two years.
Say your HR department figures out a method of processing applications that increases processing speed by 10% with no degradation in quality. Without an ERP, the head of HR (maybe) checks with their VP and then tells everyone below them to change, and that's that. Good luck making that change post-ERP.
And this is the downside to the upside I mentioned above. Steve the Secretary can't quit, but Gillian the Genius can't get hired and have a brilliant insight that rapidly streamlines processes. (Which, I suppose if you really think about it, is what enables ycombinator: large organizations with non-malleable standards need to outsource innovation. Lucky us!)
The plus side: although the cost of inter-departmental interaction change goes up, the intra-departmental change is (comparatively) easier.
I think your system could benefit in modularity, especially if the ERP were "in the hands" of the people. But that, of course, increases risks.
The bottom line: if you build for modularity (really build for it, not in the "The salesperson told me it was modular" sense) from the beginning, it would be amazing. But you have to really build for it. And I know you get that, but I don't think I can say "really" enough times here.
The BEST of luck!
[1] If you listen to marketing. There are still problems with finding things post-implementation, but I will concede these types of problems are significantly reduced. The -real- loss now is, "How do I get <x> done when the ERP doesn't want to let me?" - and THAT answer is far more valuable, in my opinion, and far less often documented.
[2] Dramatization (barely)