Followup on ERP Thread: How I Plan To Do ERP
22 comments
I work at a fortune 100 company; my only ERP interaction is occasionally entering an equipment purchase order via an Oracle system. It sucks, so you're preaching to the choir.
Nevertheless, I'd still have to ask the following:
1) Your beliefs are easy to agree with, but how do you get your first 10 customers to believe that your solution upholds these beliefs?
2) How do you sell the idea of 'writing your own' to a business person who doesn't want to become the head-contractor for a software team?
3) Keeping in mind my white-hot ignorance about this particular vein of software, I'd want to know if the problem is really with the software? Or is it a problem with understanding the process and the implications of implementing it a certain way (ie, can processes interact? do we know if they will at specification time?)
4) How smart does the tiger team need to be? An ideal system should be reasonably easy to implement by average programmers.
5) How do you sell developers on learning your platform? A customer might be concerned that not enough developers know your ERP well enough to implement future extensions.
6) How do you sell customers? You're competing against the well-oiled sales machines of your larger competitors, and all but the smallest businesses may not mind spending $1M to ensure that their all-important business processes are implemented with a well-known ERP (poorly implemented or otherwise) that they can trust their business to....
I guess one way to counter this may be to make the ERP free (open source), and have a team of core developers/contributors who could then charge $ for implementation.
Don't mistake my concerns for a lack of enthusiasm. This is a field ripe for improvement, and you seem to have the ideal background for it.
Nevertheless, I'd still have to ask the following:
1) Your beliefs are easy to agree with, but how do you get your first 10 customers to believe that your solution upholds these beliefs?
2) How do you sell the idea of 'writing your own' to a business person who doesn't want to become the head-contractor for a software team?
3) Keeping in mind my white-hot ignorance about this particular vein of software, I'd want to know if the problem is really with the software? Or is it a problem with understanding the process and the implications of implementing it a certain way (ie, can processes interact? do we know if they will at specification time?)
4) How smart does the tiger team need to be? An ideal system should be reasonably easy to implement by average programmers.
5) How do you sell developers on learning your platform? A customer might be concerned that not enough developers know your ERP well enough to implement future extensions.
6) How do you sell customers? You're competing against the well-oiled sales machines of your larger competitors, and all but the smallest businesses may not mind spending $1M to ensure that their all-important business processes are implemented with a well-known ERP (poorly implemented or otherwise) that they can trust their business to....
I guess one way to counter this may be to make the ERP free (open source), and have a team of core developers/contributors who could then charge $ for implementation.
Don't mistake my concerns for a lack of enthusiasm. This is a field ripe for improvement, and you seem to have the ideal background for it.
Thanks for the feedback. Great questions.
1. You deliver.
2. You deliver superfast.
3. My experience: 95% of the time the problem is with the software. They will willingly teach you their processes if you know how to ask and are patient enough to listen.
4. Very smart. That is one of my biggest challenges right now. My compliments on a great question.
5. Success breeds following. I don't want customers that are worried about the wrong things. There are plenty out there who aren't.
6. Every way you can. They are everywhere. I don't worry about "competing with well oiled sales machines", I relish the challenge. In the first hour, while they're still pontificating over their 4 color brochures, I can have a prototype up and running that addresses their biggest challenge. They should be worrying about me.
Great questions. Spot on. I never signed up for easy.
My experience over and over and over is: when you find out what's needed and deliver "something" very quickly that addresses it, you get their attention. Right now, I'm salivating just thinking about it.
1. You deliver.
2. You deliver superfast.
3. My experience: 95% of the time the problem is with the software. They will willingly teach you their processes if you know how to ask and are patient enough to listen.
4. Very smart. That is one of my biggest challenges right now. My compliments on a great question.
5. Success breeds following. I don't want customers that are worried about the wrong things. There are plenty out there who aren't.
6. Every way you can. They are everywhere. I don't worry about "competing with well oiled sales machines", I relish the challenge. In the first hour, while they're still pontificating over their 4 color brochures, I can have a prototype up and running that addresses their biggest challenge. They should be worrying about me.
Great questions. Spot on. I never signed up for easy.
My experience over and over and over is: when you find out what's needed and deliver "something" very quickly that addresses it, you get their attention. Right now, I'm salivating just thinking about it.
Why is this approach better than starting with Apache Open For Biz project or some other OSS ERP system (if they exist)?
http://ofbiz.apache.org/
http://ofbiz.apache.org/
It sounds like most of what you've asked can answered rather simply: Have a decent sales crew.
1) Getting your first 10 customers to believe in your product is the difficult one. But, if you can poach a VP of sales from an ERP company and have him bring his Rolodex, you should be okay. How do you poach a great VP of sales? With the right incentives. And for sales people, that incentive is lots of $$$. If you offer a sales person a generous base salary plus 10 percent of a million dollar software package. They'll be knocking your door down.
2) This is an objection that a sales person lives to answer.
3) From a sales perspective, It's the software, and our solution dramatically reduces the cost and that pain.
4) From a sales perspective, your new ERP can be built by a group of semi-literate apes and a 486.
5) Developer sales. Google for Balmer Monkey Boy Video, you'll see what I mean. It's all sales.
6) Again, sales. You don't compete on price, however. BigCo CIO's want to spend a couple million dollars on a new software package that runs the entire company. And, if you spend a couple million, dropping the odd million to fine tune the software is icing on the cake. "Last quarter we delivered a great software package to run WidgetCo. This quarter we're going to customize it special for us." quoth the CIO.
It's all sales, my comatose_kid friend. All sales.
1) Getting your first 10 customers to believe in your product is the difficult one. But, if you can poach a VP of sales from an ERP company and have him bring his Rolodex, you should be okay. How do you poach a great VP of sales? With the right incentives. And for sales people, that incentive is lots of $$$. If you offer a sales person a generous base salary plus 10 percent of a million dollar software package. They'll be knocking your door down.
2) This is an objection that a sales person lives to answer.
3) From a sales perspective, It's the software, and our solution dramatically reduces the cost and that pain.
4) From a sales perspective, your new ERP can be built by a group of semi-literate apes and a 486.
5) Developer sales. Google for Balmer Monkey Boy Video, you'll see what I mean. It's all sales.
6) Again, sales. You don't compete on price, however. BigCo CIO's want to spend a couple million dollars on a new software package that runs the entire company. And, if you spend a couple million, dropping the odd million to fine tune the software is icing on the cake. "Last quarter we delivered a great software package to run WidgetCo. This quarter we're going to customize it special for us." quoth the CIO.
It's all sales, my comatose_kid friend. All sales.
That is exactly what I'm doing for my day job. We evaluated a ton of ERP/MRP providers, and they were all A) Extremely expensive, and B) Awful. So I lobbied them to have it be made in-house.
It is currently being done with only one developer. We're 6 months into the implementation, and are piloting in several of the modules. It is going pretty well so far.
If it continues to go well, we're considering spinning it out into its own company. A well-designed and user-friendly ERP system is a killer asset to have, and being able to resell it is an even bigger one.
I've come to pretty much the same conclusion as you, about customizing. I figured we'd have a "standard" set of modules, which would either be completely replaced or slightly modified as necessary to fit the client company. Certain things like maintenance, receiving, purchase orders and sales teams probably don't vary much between companies. Other things like manufacturing routers and change orders probably do. This would allow us to be flexible where it is necessary, and to reuse code where it is not.
As a side note, we're hiring another developer to work on this system. IC to start. Let me know if you're interested.
It is currently being done with only one developer. We're 6 months into the implementation, and are piloting in several of the modules. It is going pretty well so far.
If it continues to go well, we're considering spinning it out into its own company. A well-designed and user-friendly ERP system is a killer asset to have, and being able to resell it is an even bigger one.
I've come to pretty much the same conclusion as you, about customizing. I figured we'd have a "standard" set of modules, which would either be completely replaced or slightly modified as necessary to fit the client company. Certain things like maintenance, receiving, purchase orders and sales teams probably don't vary much between companies. Other things like manufacturing routers and change orders probably do. This would allow us to be flexible where it is necessary, and to reuse code where it is not.
As a side note, we're hiring another developer to work on this system. IC to start. Let me know if you're interested.
If you're developing an in-house system you should try to stay away from thinking about spinning out into a separate company. If/when you are successful you can asses what is needed to make the software into a viable product. I would focus on building something that works for in-house use only and not try to make it any more modular or extensible than absolutely necessary.
"we'd have a "standard" set of modules, which would either be completely replaced or slightly modified as necessary to fit the client company"
This is what a dozen of my customers have suggested. (You know you're on the right track when your customers are pushing you into a business.) I'm doing something like this but with a few twists.
Thanks for the side note. I have start-up fever and am married to my project. But I'd love to stay in touch.
This is what a dozen of my customers have suggested. (You know you're on the right track when your customers are pushing you into a business.) I'm doing something like this but with a few twists.
Thanks for the side note. I have start-up fever and am married to my project. But I'd love to stay in touch.
"Vanilla is the best flavor."
One of the smartest healthcare IT managers I have dealt with said that regarding enterprise hospital software. The major hospital products have the same issues as ERP products: they are very expensive and implementation projects tend to involve a lot of painful customization. After getting burned a few times that manager swore off customization altogether. Now if they decide to buy a commercial product they implement it as-is, even if that means changing the business workflow to accomodate the software. Over the long run this has delivered much better results.
I don't have much direct experience with ERP but I question whether all those businesses are unique and special snowflakes that really need custom software. Are organizational differences in common areas like inventory control and accounting actually adding any value? In most cases I think they could be standardized without any long-term loss. So then the only reason to customize is to avoid the short-term pain of reengineering current processes.
I don't think your idea is stupid. There are already plenty of other custom development shops doing similar work. So if you hustle and deliver results I'm sure you can win a decent share. But unless you focus more on building a real product I think you may get stuck at just having a small "lifestyle" business rather than something that would be attractive to VCs.
One of the smartest healthcare IT managers I have dealt with said that regarding enterprise hospital software. The major hospital products have the same issues as ERP products: they are very expensive and implementation projects tend to involve a lot of painful customization. After getting burned a few times that manager swore off customization altogether. Now if they decide to buy a commercial product they implement it as-is, even if that means changing the business workflow to accomodate the software. Over the long run this has delivered much better results.
I don't have much direct experience with ERP but I question whether all those businesses are unique and special snowflakes that really need custom software. Are organizational differences in common areas like inventory control and accounting actually adding any value? In most cases I think they could be standardized without any long-term loss. So then the only reason to customize is to avoid the short-term pain of reengineering current processes.
I don't think your idea is stupid. There are already plenty of other custom development shops doing similar work. So if you hustle and deliver results I'm sure you can win a decent share. But unless you focus more on building a real product I think you may get stuck at just having a small "lifestyle" business rather than something that would be attractive to VCs.
"Are organizational differences in common areas like inventory control and accounting actually adding any value?"
Absolutely! That's the entire basis for my business. If there was anything remotely close to what my customers have been asking for, I'd be out selling it.
"In most cases I think they could be standardized without any long-term loss."
That's why you and I hack and our customers run businesses. It took me a long time to learn it, but now I listen to what they say, not what I think.
Absolutely! That's the entire basis for my business. If there was anything remotely close to what my customers have been asking for, I'd be out selling it.
"In most cases I think they could be standardized without any long-term loss."
That's why you and I hack and our customers run businesses. It took me a long time to learn it, but now I listen to what they say, not what I think.
Incidentally, this is how all software used to be. When software was an add-on to the millions of dollars of hardware you bought, all the software was custom-written for the purchasing business. Once computers got cheap enough that many, many more businesses could afford them, there was an economy of scale that enabled mass-produced shrink-wrapped software. When the software cost went from hundreds of thousands of dollars down to thousands of dollars, businesses changed their practices to match the packaged software because it was cheaper than writing custom.
I'm not sure what would ignite that change in ERP because I think the number of businesses that need that scale of organization isn't going to increase dramatically, so there won't be economies of scale. I guess a valid question would be - how many companies aren't using an ERP at all that would benefit if one was available at the right price? My computer centric view makes me forget that some people still use paper and pencil, land lines, and write checks.
I'm not sure what would ignite that change in ERP because I think the number of businesses that need that scale of organization isn't going to increase dramatically, so there won't be economies of scale. I guess a valid question would be - how many companies aren't using an ERP at all that would benefit if one was available at the right price? My computer centric view makes me forget that some people still use paper and pencil, land lines, and write checks.
Great minds etc.
I was also looking at ERP after working in the field for a number of years. I was planning on coming from a very different angle. Hosting a very configurable system that required little or no manual intervention. Aiming at small business for a $20 per month per user fee.
Then I discovered I hate running a business, not just dis-like but hate so much I never want to do it again :-(
I think your idea could take off but the software has to be malleable, this is in contrast to nearly every piece of software written to this day which is brittle. I was looking at this as just a way to predict how software will be written in the future.
First off read a couple of books to understand better where I'm coming from :-
The above would give you a group of objects that you can model the business with and forget about technical details.
Then the underlying system could be built e.g. fully temporal, fully redundant etc. etc.
The idea being that you could focus on business processes without thinking about implementation details. In true naked object style the UI would be automatically generated from the business action/process classes.
To make what you are thinking about work _ALL_ design has to be KISS and DRY. Also, the more you can generate the better you'd be.
I was thinking of using Lisp or SmallTalk to gain an advantage, must use a VM to be able to separate business from technical. I want to my software running 24/7 with zero downtime including during upgrades, automatic rudundancy, load balancing etc.
If you are thinking of something along these lines then drop me a line and I'd love to help.
If you just want to re-implement the current paradigm don't bother contacting me. The current paradigm is so broken it's not even funny.
I was also looking at ERP after working in the field for a number of years. I was planning on coming from a very different angle. Hosting a very configurable system that required little or no manual intervention. Aiming at small business for a $20 per month per user fee.
Then I discovered I hate running a business, not just dis-like but hate so much I never want to do it again :-(
I think your idea could take off but the software has to be malleable, this is in contrast to nearly every piece of software written to this day which is brittle. I was looking at this as just a way to predict how software will be written in the future.
First off read a couple of books to understand better where I'm coming from :-
Necessary But Not Sufficient by Eliyahu M. Goldratt
Naked Objects by Richard Pawson
The above would give you a group of objects that you can model the business with and forget about technical details.
Then the underlying system could be built e.g. fully temporal, fully redundant etc. etc.
The idea being that you could focus on business processes without thinking about implementation details. In true naked object style the UI would be automatically generated from the business action/process classes.
To make what you are thinking about work _ALL_ design has to be KISS and DRY. Also, the more you can generate the better you'd be.
I was thinking of using Lisp or SmallTalk to gain an advantage, must use a VM to be able to separate business from technical. I want to my software running 24/7 with zero downtime including during upgrades, automatic rudundancy, load balancing etc.
If you are thinking of something along these lines then drop me a line and I'd love to help.
If you just want to re-implement the current paradigm don't bother contacting me. The current paradigm is so broken it's not even funny.
The quality (and apparent sincerity) of your reply merit a full inhaling of your 2 references. I'm off to Amazon as soon as I finish typing this.
"The idea being that you could focus on business processes without thinking about implementation details."
Bingo! In 18 months of sharing this concept, I think you may have closest to understanding it (or at least explaining your understanding).
"Then I discovered I hate running a business, not just dis-like but hate so much I never want to do it again :-("
I may be the yin for your yang. I can't wait to have a business to run and customers to serve! Seeing a customer achieve their goals with my support is like oxygen to me. I have to have it. I love hacking, but it's only a means to an end. If I had something to implement, I'd be implementing, not hacking.
Kindly put your email address on your profile and stay in touch.
"The idea being that you could focus on business processes without thinking about implementation details."
Bingo! In 18 months of sharing this concept, I think you may have closest to understanding it (or at least explaining your understanding).
"Then I discovered I hate running a business, not just dis-like but hate so much I never want to do it again :-("
I may be the yin for your yang. I can't wait to have a business to run and customers to serve! Seeing a customer achieve their goals with my support is like oxygen to me. I have to have it. I love hacking, but it's only a means to an end. If I had something to implement, I'd be implementing, not hacking.
Kindly put your email address on your profile and stay in touch.
I'm in the same boat as ajmoir. I thought of implementing is as a DSL for businesses - let the "tigers" specify it in the DSL and then the implementation can be upgraded underneath the definition. Naturally, Lisp would be a good fit. I do enjoy the success of seeing customers achieve goals, but I prefer the tractability of engineering systems over the political systems of the real world. I'd certainly love to hack for businesses if there was a thin wrapper over them (ie business oriented cofounder). I've already emailed you expressing interest in your project, so keep me in mind too!
I haven't read naked objects - maybe that would help me get over my general distrust of OO. Thanks for the recommendation!
I haven't read naked objects - maybe that would help me get over my general distrust of OO. Thanks for the recommendation!
I'm sure we'll be talking again. In the meantime, save $60 (for the time being) and get started on-line:
http://www.nakedobjects.org/book/content.html
http://www.nakedobjects.org/book/content.html
I worked at Black & Decker for 5 years implementing SAP. I also wrote custom software to integrate into SAP when their modules didn't "fit" B&D's needs. A Manufacturing operation is really an incredible orchestration of different people in different departments, but those departments incentives and measurements aren't always aligned with one another. A large ERP system like SAP makes these departments tightly integrated and there is a lot of battling for territory. One department may make and entry to move inventory around for their own purposes and that will affect another department adversely. My experience makes me believe that ERP systems should take a more loosely coupled approach so that each department can have it's on custom software and communicate with other departments via a standard interface like XML. Also don't discount the fact that some corporations benefit from the inflexibility of ERP software. Most high level people I worked with liked the fact that they could dictate from a high level how things were to be carried out, even if they weren't the people who knew the process the best. I can promise anyone who interviews 4 different people in a manufacturing plant, at different managerial levels, about processes in the plant, will receive at least 3 different answers. Every guy there thinks he knows what is best and he controls his fiefdom how he sees fit. Very often the Corporation uses software to dictate to him how he will do his job, and that person will usually bitch about the ERP system because if they bitched about the plant manager they would get canned. You are tackling a huge problem and I would be interested in keeping up with your progress, so if you need anyone to bounce anything off of...feel free to drop me a line.
In my experience, the best way to break in is to find a process that either isn't handled or handled only tangentially by existing ERP packages. It helps too if that process represents a new way of doing business for your customers. That way you get to pitch for growing the top-line (i.e. creating dollars that didn't exist before your software came on the scene) vs. bottom-line savings that just cut costs.
Not to throw cold water on your idea, but I have deep reservations that pure technical expertise in generic enterprise development/implementation will win anyone over. All of the big guys plus numerous other consulting companies already offer this, with much more name recognition (deserved or not) than you will have. Additionally, one of the main features of packaged software is that customers not only are loathe to manage a development process, they are reluctant to even engage one in the first place.
But if you can distinguish yourself by being The Smartest and Best (TM) in a particular business area, all of your skills in execution can back that up and create a winning operation. But without that domain focus and expertise the story is much less compelling.
Not to throw cold water on your idea, but I have deep reservations that pure technical expertise in generic enterprise development/implementation will win anyone over. All of the big guys plus numerous other consulting companies already offer this, with much more name recognition (deserved or not) than you will have. Additionally, one of the main features of packaged software is that customers not only are loathe to manage a development process, they are reluctant to even engage one in the first place.
But if you can distinguish yourself by being The Smartest and Best (TM) in a particular business area, all of your skills in execution can back that up and create a winning operation. But without that domain focus and expertise the story is much less compelling.
Here's the biggest challenge I think you face. Because ERP is so entwined in a how a company does business, it's really hard to create a "bottom-up" solution. Executives have to be involved, you'll need sales people to explain things, and - most important - you won't really know how it goes until after the implementation. This means there is little incentive to create good software. Once the customer has spent a ton of time customizing it and retraining employees, they're not going to switch away just because the product kind of sucks. The highest quality software is found in consumer apps like GMail that are really easy to switch away from.
Is there any way you can make your solution have minimal up front cost and to be rolled in gradually, similar to the way that Salesforce and now Google Apps spread? That way you can compete just based on quality - not on sales ability. That will in turn force you to make the solution great, and you'll end up kicking everyone's ass.
Is there any way you can make your solution have minimal up front cost and to be rolled in gradually, similar to the way that Salesforce and now Google Apps spread? That way you can compete just based on quality - not on sales ability. That will in turn force you to make the solution great, and you'll end up kicking everyone's ass.
"Here's the biggest challenge I think you face. Because ERP is so entwined in a how a company does business, it's really hard to create a "bottom-up" solution."
Right! That's why packages are the default.
The way to break the "software package mindset" is to learn how to conduct analysis. There are a lot of good hackers out there, but hardly anyone knows how to do analysis anymore.
There's not much magic here. Just unrelenting legwork...
"So, Joe, what do you do with the Work Order Traveler when Julie runs out of X17 components? You give it to Fred? Fred, what do you do with it? What, Joe doesn't really give it to you, he passes it by Jose first? Is this true, Julie? Why does Jose need to see it?..."
"Then what happens?"
"What do you do if...?"
"How do you know if...?"
How do you know when you're done. When everyone agrees that you're done. Then you build it.
Ever seen anyone do this well? I didn't think so.
Right! That's why packages are the default.
The way to break the "software package mindset" is to learn how to conduct analysis. There are a lot of good hackers out there, but hardly anyone knows how to do analysis anymore.
There's not much magic here. Just unrelenting legwork...
"So, Joe, what do you do with the Work Order Traveler when Julie runs out of X17 components? You give it to Fred? Fred, what do you do with it? What, Joe doesn't really give it to you, he passes it by Jose first? Is this true, Julie? Why does Jose need to see it?..."
"Then what happens?"
"What do you do if...?"
"How do you know if...?"
How do you know when you're done. When everyone agrees that you're done. Then you build it.
Ever seen anyone do this well? I didn't think so.
Sounds like you have a track record, you've hit upon a legitimate pain that people would pay to make go away, and you're starting to think about how to fix this by doing it, which is probably the only way to do it.
This puts you way ahead of a lot of other entrepreneurs.
This puts you way ahead of a lot of other entrepreneurs.
Thanks. For years, I've toiled in an area where there's often not much logic. I've always said, "There's gotta be a better way." Now is my chance to put my money where my mouth is.
Your complaints are not limited to ERP systems; I can certainly vouch for this viewpoint.
I think you biggest problems is going to find the first few clients. Nobody is going to believe you when you say that you can do more with less. Elephants in the room are impossible to see before you tear down the wall and lead it out into the sunshine.
Any ideas? I'm in a similar situation regarding group benefits administration, and I think I could even pull a sale or two based on past encounters, but you're talking about changing entire industries (and shifting a lot of profits in the process) here.
I think you biggest problems is going to find the first few clients. Nobody is going to believe you when you say that you can do more with less. Elephants in the room are impossible to see before you tear down the wall and lead it out into the sunshine.
Any ideas? I'm in a similar situation regarding group benefits administration, and I think I could even pull a sale or two based on past encounters, but you're talking about changing entire industries (and shifting a lot of profits in the process) here.
You're right. It's hard to get started. But they're out there. Everywhere. They just don't know what to do and where to turn. Finding a way to get connected is one of the biggest early challenges.
You need to find a CEO willing to take a chance. I'd look at one who has built a smaller company from scratch, (say 250 ee's) and is now finding it difficult to expand into the leagues of the big boys. He/she is looking for an edge, and is likely to take a risk to obtain it.
The worry there is you have to have a big part of your business be for a sales force to cater to these large companies which take forever to make up their mind - unless I'm missing something?
Yes, large companies do that. I'd rather pick the lower hanging fruit. Small and midmarket companies often approach me with ideas and questions. THEY are the ones I'm targeting.
(Just for a laugh, go to any local Chamber of Commerce or Tech meeting. Ask how much they like their business software on a scale of 1 to 10. Take plenty of business cards and find a way to deliver "something".)
(Just for a laugh, go to any local Chamber of Commerce or Tech meeting. Ask how much they like their business software on a scale of 1 to 10. Take plenty of business cards and find a way to deliver "something".)
This business adventure seems GREAT! I totally agree that each company needs software designed to their needs not that their needs must revert to match the software.
However, Your biggest problem is going to be. Can the company truly convey their needs so that you the programmer can build an ERP system for them.
Yes a Tiger Team can aide in this process but it has been my experience that not all companies are aware of all their assets when it comes to selecting a team that can convey their needs.
However, Your biggest problem is going to be. Can the company truly convey their needs so that you the programmer can build an ERP system for them.
Yes a Tiger Team can aide in this process but it has been my experience that not all companies are aware of all their assets when it comes to selecting a team that can convey their needs.
I hate to sound harsh, but there's nothing here to disagree with. You're not taking any deep principled stand. You're saying "I like puppies." and "Ice cream is yummy."
What is your system NOT going to to do?
What are you going tell you customers you WON'T do?
If you're just saying YES to everything, there's nothing left to argue. And, from my experience, the company will die a death from a thousand papercuts as your sunk under the weight of over-promising.
What is your system NOT going to to do?
What are you going tell you customers you WON'T do?
If you're just saying YES to everything, there's nothing left to argue. And, from my experience, the company will die a death from a thousand papercuts as your sunk under the weight of over-promising.
So then, all I have to do is deliver what I promise, right?
At one level, yes.
But again, that's feel like an empty platitude.
The exercise I think you should consider is examining what you're NOT going to do. Don't reduce this to a BS exercise interview question of "What are my weaknesses" and answering "working too hard."
Give it a real go: figure out what requests you're going to answer NO to.
Look, I don't mean to be harsh, but is really, really easy to say YES. It's our default setting. Especially if you're in sales.
But if you don't figure out how to say NO, then delivering is extraordinarily difficult.
Start small: say no to clients that are too big (or too small). Set a threshold. Limit the number of backends you have to interface to. Limit it to non-realtime.
But try to bound the product to something you CAN deliver.
But again, that's feel like an empty platitude.
The exercise I think you should consider is examining what you're NOT going to do. Don't reduce this to a BS exercise interview question of "What are my weaknesses" and answering "working too hard."
Give it a real go: figure out what requests you're going to answer NO to.
Look, I don't mean to be harsh, but is really, really easy to say YES. It's our default setting. Especially if you're in sales.
But if you don't figure out how to say NO, then delivering is extraordinarily difficult.
Start small: say no to clients that are too big (or too small). Set a threshold. Limit the number of backends you have to interface to. Limit it to non-realtime.
But try to bound the product to something you CAN deliver.
While I agree that it's a good idea to start with some limits, with a business model like this (few customers, mucho $$/customer), it's probably better to let the first few customers dictate what to start out with. Of course the early product can't be everything to everyone, but it can be everything to one client! Then it's a base to build off of, finding the next client with similar needs and adding the diff to the product base. This way, as the diversity of customers grows, the product will grow with the business and open new opportunities.
Having said that, I'm curious to know what you think your first customers will be like (size, industry, etc).
Having said that, I'm curious to know what you think your first customers will be like (size, industry, etc).
"there's nothing left to argue"
Good. Then the trafficing of enterprise data will be permitted within limits, edw519 will provide software in the east, and there will be the peace.
(Apologies to Mario Puzo)
Good. Then the trafficing of enterprise data will be permitted within limits, edw519 will provide software in the east, and there will be the peace.
(Apologies to Mario Puzo)
This is all about business processes, application integrations, and integrity (and security) of data.
Think SOA, ESB. Combine that with Utility computing (Amazon EC2, IBM, Microsoft, and Google also entering that space eventually) and many many provider's with connected or disconnected processes but with compliant interfaces into the extended (internet) service bus...
Big fat ERP is so 4 years ago.
Think SOA, ESB. Combine that with Utility computing (Amazon EC2, IBM, Microsoft, and Google also entering that space eventually) and many many provider's with connected or disconnected processes but with compliant interfaces into the extended (internet) service bus...
Big fat ERP is so 4 years ago.
> CUSTOM ENTERPRISE SOFTWARE IS THE ONLY WAY TO GO.
I don't want to be repetitive, but this is the same conclusion the OFBiz guys arrived at, which is why they have a very flexible, open system that is licensed under a liberal license. I'm not wild about all the Java and XML involved, but they've got a really good community going, which counts for a lot.
I don't want to be repetitive, but this is the same conclusion the OFBiz guys arrived at, which is why they have a very flexible, open system that is licensed under a liberal license. I'm not wild about all the Java and XML involved, but they've got a really good community going, which counts for a lot.
I won't tell you your plan is stupid. On the contrary, I believe it's an idea whose time has come (I think it's come more than once). Nor will I say that it won't work, though it will certainly be a hard road to slog.
I comment as someone involved in roughly three dozen ERP implementations (along with a dozen or so CRM and HRMS) over the past decade, for a number of mid-market and larger enterprises (mostly North American, a few international), across the manufacturing, software, healthcare, and pharmaceutical industries, in many roles ranging from developer, to technical architect, to implementation manager.
We have a number of experiences and opinions in common: (a) I too haven't seen (nor met someone who has seen) a class A implementation, (b) I'm still appalled at the poorness-of-fit and poor quality of this class of software, (c) I remain utterly unconvinced that the current model of ERP software development and implementation will _ever_ produce a modest-cost system.
Of your line "No two businesses are alike", nothing could be more true, and nothing could be more at the heart of the misfit between desire and reality in this software space.
Every business has grown their own a wide variety of their own processes. In smaller businesses, these process are unique. In larger ones, these are fairly standard, but only to a point. There isn't a single company where one can 'drop-in' a business process from another company and have it work without mistake. (You realize the impossibility of this by how silly my example sounds.)
Not only are there dissimilarities between businesses that prevent standardized software from working out-of-the-box, there are also dissimilarities within businesses that make the off-the-shelf solution unappealing.
Consider that a good number of mid-sized and large businesses are an ungodly combination of merged, acquired, downsized, and spun-off companies. (Somewhat like the custom firetruck manufacturer you used in your example.) How often does the surviving company from a merger, acquisition, or spin-off cleanly adopt a uniform set of business processes from their predecessor organization(s)? In my experience, not very often. You will find many pockets of heavily-resistant 'non-standardization' in mid-sized and large firms.
So no two businesses are alike from the outside, and few are even uniform from within. Now consider how many forces of change are pressing on a given organization.
New management: how often has the new CEO, new division head, new head of operations come in wanting to put "their stamp on the place" and decided that the old way of doing things just won't work? The new sales head decides a territory realignment and new incentive compensation plan is the way to start. Hey Mr. ERP? We need something from you.
New competitive responses: Oh I see that our main competitor now has a new offering that completely sinks ours. Time for more than a SKU respin, time for a whole new product, new packaging, new bundling, new discount strategy. Hey Mr. ERP? We need something else from you.
New channel strategies: Your distributors and their resellers are now pressing you on margin, they're demanding better insight into supply chain, their business systems are better, faster, and more responsive than yours. Hey Mr. ERP? Here's another thing we need from you.
New regulatory environments: Sure you can usually see these things coming years ahead (HIPAA, Sarb-Ox), but they demand change to the business, which means change to the businesses software systems. Hey Mr. ERP? Are you listening?
New IT changes: moving from Unix to Windows, moving from self-hosted to colocated, moving from insourced to outsourced, moving from here to hell and back. Hey Mr. ERP? I'll understand if you want to stick the shiv in yourself and save me the bother.
Lightly into this morass tapdances the ERP software industry. It promises the essentially undeliverable: we can sell you a bunch of software that _will_ allow you to uniformly conduct business across your enterprise. Forget about all of the sources of non-uniformity described above, and forget about the fact that your business is itself different from one division to the next, and from one year to the next, and that change is a constant. We'll give you a modular system which you can glue together (using the expensive services of our various third-party partners) to fit your unique business requirements.
Strangely familiar lyrics? That's right. You're listening to the pied piper. Keep your children close at hand.
But, you say, the ERP industry _is_ doing this (for WalMart, for Boeing, for the Home Depot; for 3M, for AT&T, for Staples; heck, even for your neighbor's mid-sized $50M dollar electronics manufacturer, or your former bosses $20M industrial supply firm.)
Just how are _these_ companies making ERP work? They're squeezing their size 12 body, with their 38DDs, into that svelte little one piece they saw on the runway, hoping like hell a seam won't bust before the photographer gets the money shot in the bag. Short answer? They're shoe-horning their business into the ERP-maker's box.
If one of their existing business processes doesn't fit, they'll stop performing that process to make themselves 'work' with the software. If one of their processes is more efficient, they'll forgo efficiency for the sake of harmony with the software. If an existing practice gave them the flexibility to deal with odd customer requests, they'll become rigid in order to keep from changing the software.
In the end, though they don't know it, they've tied themselves to a rock, and are slowly wading into deep water. Yes, they're now standardized and have mated their business to an ERP, but the real cost of doing so is a hidden one. Everyday, their business loses time, money, efficiency, and customer goodwill, as their business now does business according to the dictates of the ERP firm.
Sure, it's natural for ERP proponents to counter that the business is now truly more efficient for having standardized their business processes across the board, is now faster as the computer can calculate things much faster than people could, and is far less error-prone by being able to check and double-check things in real-time.
Well there's no point in getting into a huge he-said, she-said over this. Just ask yourself, though, when was the last time you truly ever saw a real apples-to-apples comparison of the cost-benefits of an ERP implementation? May I say, after having been involved in well over 30 of these myself, I've never seen a real comparison. I've talked to many colleagues, who've also never seen a real one.
So all the damage behind this is what (I presume) prompts your idea.
Forget about the large-scale ERP software packages--they are too bloated to be the right fit for any single organization, too crufty a code base to ever be called well-written and maintainable, and too buggy to be reliable, bet-your-business platforms.
And yet, it's not as though the ERP makers deliberately set out to write shitty software. At one time or other in the distant past, they hired some really smart people, and had them grew some fairly impressive software. Impressive (when viewed through the eyes of a software developer, at least) for it's depth, breadth, flexibility, documentation, platform adaptability, updateability, price, etcetera.
So there's a lot for you to do, and a great deal of resistance to overcome. I wish you the best of luck.
I comment as someone involved in roughly three dozen ERP implementations (along with a dozen or so CRM and HRMS) over the past decade, for a number of mid-market and larger enterprises (mostly North American, a few international), across the manufacturing, software, healthcare, and pharmaceutical industries, in many roles ranging from developer, to technical architect, to implementation manager.
We have a number of experiences and opinions in common: (a) I too haven't seen (nor met someone who has seen) a class A implementation, (b) I'm still appalled at the poorness-of-fit and poor quality of this class of software, (c) I remain utterly unconvinced that the current model of ERP software development and implementation will _ever_ produce a modest-cost system.
Of your line "No two businesses are alike", nothing could be more true, and nothing could be more at the heart of the misfit between desire and reality in this software space.
Every business has grown their own a wide variety of their own processes. In smaller businesses, these process are unique. In larger ones, these are fairly standard, but only to a point. There isn't a single company where one can 'drop-in' a business process from another company and have it work without mistake. (You realize the impossibility of this by how silly my example sounds.)
Not only are there dissimilarities between businesses that prevent standardized software from working out-of-the-box, there are also dissimilarities within businesses that make the off-the-shelf solution unappealing.
Consider that a good number of mid-sized and large businesses are an ungodly combination of merged, acquired, downsized, and spun-off companies. (Somewhat like the custom firetruck manufacturer you used in your example.) How often does the surviving company from a merger, acquisition, or spin-off cleanly adopt a uniform set of business processes from their predecessor organization(s)? In my experience, not very often. You will find many pockets of heavily-resistant 'non-standardization' in mid-sized and large firms.
So no two businesses are alike from the outside, and few are even uniform from within. Now consider how many forces of change are pressing on a given organization.
New management: how often has the new CEO, new division head, new head of operations come in wanting to put "their stamp on the place" and decided that the old way of doing things just won't work? The new sales head decides a territory realignment and new incentive compensation plan is the way to start. Hey Mr. ERP? We need something from you.
New competitive responses: Oh I see that our main competitor now has a new offering that completely sinks ours. Time for more than a SKU respin, time for a whole new product, new packaging, new bundling, new discount strategy. Hey Mr. ERP? We need something else from you.
New channel strategies: Your distributors and their resellers are now pressing you on margin, they're demanding better insight into supply chain, their business systems are better, faster, and more responsive than yours. Hey Mr. ERP? Here's another thing we need from you.
New regulatory environments: Sure you can usually see these things coming years ahead (HIPAA, Sarb-Ox), but they demand change to the business, which means change to the businesses software systems. Hey Mr. ERP? Are you listening?
New IT changes: moving from Unix to Windows, moving from self-hosted to colocated, moving from insourced to outsourced, moving from here to hell and back. Hey Mr. ERP? I'll understand if you want to stick the shiv in yourself and save me the bother.
Lightly into this morass tapdances the ERP software industry. It promises the essentially undeliverable: we can sell you a bunch of software that _will_ allow you to uniformly conduct business across your enterprise. Forget about all of the sources of non-uniformity described above, and forget about the fact that your business is itself different from one division to the next, and from one year to the next, and that change is a constant. We'll give you a modular system which you can glue together (using the expensive services of our various third-party partners) to fit your unique business requirements.
Strangely familiar lyrics? That's right. You're listening to the pied piper. Keep your children close at hand.
But, you say, the ERP industry _is_ doing this (for WalMart, for Boeing, for the Home Depot; for 3M, for AT&T, for Staples; heck, even for your neighbor's mid-sized $50M dollar electronics manufacturer, or your former bosses $20M industrial supply firm.)
Just how are _these_ companies making ERP work? They're squeezing their size 12 body, with their 38DDs, into that svelte little one piece they saw on the runway, hoping like hell a seam won't bust before the photographer gets the money shot in the bag. Short answer? They're shoe-horning their business into the ERP-maker's box.
If one of their existing business processes doesn't fit, they'll stop performing that process to make themselves 'work' with the software. If one of their processes is more efficient, they'll forgo efficiency for the sake of harmony with the software. If an existing practice gave them the flexibility to deal with odd customer requests, they'll become rigid in order to keep from changing the software.
In the end, though they don't know it, they've tied themselves to a rock, and are slowly wading into deep water. Yes, they're now standardized and have mated their business to an ERP, but the real cost of doing so is a hidden one. Everyday, their business loses time, money, efficiency, and customer goodwill, as their business now does business according to the dictates of the ERP firm.
Sure, it's natural for ERP proponents to counter that the business is now truly more efficient for having standardized their business processes across the board, is now faster as the computer can calculate things much faster than people could, and is far less error-prone by being able to check and double-check things in real-time.
Well there's no point in getting into a huge he-said, she-said over this. Just ask yourself, though, when was the last time you truly ever saw a real apples-to-apples comparison of the cost-benefits of an ERP implementation? May I say, after having been involved in well over 30 of these myself, I've never seen a real comparison. I've talked to many colleagues, who've also never seen a real one.
So all the damage behind this is what (I presume) prompts your idea.
Forget about the large-scale ERP software packages--they are too bloated to be the right fit for any single organization, too crufty a code base to ever be called well-written and maintainable, and too buggy to be reliable, bet-your-business platforms.
And yet, it's not as though the ERP makers deliberately set out to write shitty software. At one time or other in the distant past, they hired some really smart people, and had them grew some fairly impressive software. Impressive (when viewed through the eyes of a software developer, at least) for it's depth, breadth, flexibility, documentation, platform adaptability, updateability, price, etcetera.
So there's a lot for you to do, and a great deal of resistance to overcome. I wish you the best of luck.
What is ERP?
ERP = Enterprise Resource Planning
In this context, you're buying a database and an application to manage inventory. And people. But people are just inventory with different expiration dates. They really are designed to do contain EVERYTHING a business does. If there's a procedure for doing something, it needs to be in the ERP.
You mostly have two options in the status quo, as the poster said: Pay to have it customized ($10,000,000 total budget (hardware+software) for a 4,000 employee organization isn't unusual) or conform to the ERPs methodology.
In this context, you're buying a database and an application to manage inventory. And people. But people are just inventory with different expiration dates. They really are designed to do contain EVERYTHING a business does. If there's a procedure for doing something, it needs to be in the ERP.
You mostly have two options in the status quo, as the poster said: Pay to have it customized ($10,000,000 total budget (hardware+software) for a 4,000 employee organization isn't unusual) or conform to the ERPs methodology.
Thanks for the info.
I must admit, it sounds like a horrible idea to me... I strongly believe that business processes should be able to evolve, which would presumably not be the case with very expensive software (every change is complicated and expensive). The evolution should also be bottom up - the people involved in a process should be given the ability to change it, if they see that it has flaws.
It sounds to me as if ERP is just a LOT of TPS reports waiting to be written...
I must admit, it sounds like a horrible idea to me... I strongly believe that business processes should be able to evolve, which would presumably not be the case with very expensive software (every change is complicated and expensive). The evolution should also be bottom up - the people involved in a process should be given the ability to change it, if they see that it has flaws.
It sounds to me as if ERP is just a LOT of TPS reports waiting to be written...
For big companies the continued survival is stability in their operating process. ERP plays heavily into the role of managing large amount of resources.
When I gaze into my crystal ball, I see Amazon offering the best components of their ERP system as API-based services. Web developers will move up the value chain and provide custom interfaces for companies who want that.
Your analysis, as far as it goes, is spot-on. Here's a link to somebody else who appears to share your vision: http://www.thingamy.com
Go tiger, go!
Go tiger, go!
Cool link. Thank you.
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.
[2] Dramatization (barely)
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)
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.
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.
Thanks for the comments.
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.
Thanks for the comments.
If you get the execution right you are headed for greatness :-)
You are spot on.
How about in some way using emacs? The tiger team would develop the elisp needed to cater to the company.
First a little of my background. I have built a career working on roughly 30 clients' ERP systems. They ranged from $1 million in annual revenues up to about $100 million with a several more in the Fortune 1000. Many different industries were represented, mostly in manufacturing, distribution, and retail. I also wrote several modules for ERP software vendors.
My "typical" assignment went something like this: We bought this extremely expensive state-of-the-art ERP system that our auditors insisted we get (and probably received a kick-back for). We got the thing up and running, but it doesn't do business the way we do, so we are hurting. It must do <requirement>. We do have the source code (at least someone was thinking). We want you to get <requirement> to work. As long as I had the source code, I was always able to satisfy their requirements.
I realize that my view may be a little skewed because I only got calls from clients in pain, but in all those years:
- I never saw a Class A ERP Implementation.
- I never met anyone who saw a Class A ERP Implementation.
- I am still shocked by how expensive software and services are.
- I am still shocked by how utterly poor the software is.
- I am not surprised by how ineffective ERP (and enterprise software in general) is.
Because the software is so complex (sometimes for good reason, often not), the general concensus is that it's too hard to write your own; you must buy a package. Since the software is already written and field tested in other businesses, then you should be way ahead. But you're not. Here's why.
No two businesse are exactly alike. Often not even close. The very act of survival requires many businesses to differentiate themselves to find a competitive edge. This differentiation is often in an area already standardized by their packaged software. So it doesn't work. And can't. I've seen it over and over again, in every function of the business. The nomenclature for SKUs, customers, vendors, you name it, the method of processing orders (sales, work, purchasing), accounting methods, unique ways of marketing, selling, pricing, branding,... I could go on and on, but you get the idea. It could be anything, and as soon as it's in a function controlled by your standardized software package, you have a choice: do it their way with their software or do it your way without the software. Or call someone like me.
Then there's the elephant in the living room problem: the software is loaded with bugs to begin with, complicated to use, and difficult, expensive, and time consuming to implement.
After living this life for too many years, I have developed several beliefs:
- If a business is satisfied with a process, then the software should be made to support the process, not the other way around.
- Quality software has an extremely solid base, is well written, and easily maintained.
- Good software requires little or no training, documentation, or procedures, and is ALWAYS easy to use.
- The current state of packaged enterprise software is almost the exact opposite of everything that I believe in.
- Many business people are dying for what they really want while tolerating what they have.
- Current web-based technologies (and people like us) have finally made the unthinkable possible:
CUSTOM ENTERPRISE SOFTWARE IS THE ONLY WAY TO GO.
25 years ago, everyone laughed when the engineers from Wang, DEC, HP, and Qantel put ERP on mini-computers. It'll never run, they said. It did. Then they laughed when the next generation of engineers got it to run client-server. But that ran, too. Now they'll laugh when a nut like me starts telling my customers that they don't need to buy an ERP package anymore. They can roll their own with modern technology and people like those on this board. Between AJAX, web apps, new languages, frameworks, and platforms, and the people who know how to use them, it is now becoming more effective to write your own.
The critical path will once again be the analysis phase - determining exactly what to build. This has always been and will probably continue to be the weakest link; so few know how to do it well.
So here's what I'm doing. I'm NOT writing an ERP package. I'm building a platform and methodology upon which a small but very effective "tiger team" of analysts and developers can roll out a custom enterprise solution for any small or mid market business. A solution without compromise, better than any "lowest common denominator" software package available, even in their SIC code. Something that can be delivered in weeks or months, not years, and can be priced competitively and reasonably.
I welcome feedback on what I've just presented here, but please don't tell me it's stupid or won't work. I've already heard plenty of that. I'd rather not share much detail in a public forum like this one, but would be glad to continue this discussion with anyone who'd like to.