
Followup on ERP Thread: How I Plan To Do ERP - edw519
This is a follow up to an earlier thread about a custom firetruck manufacturer who went bankrupt because of a bad ERP implementation.  I mentioned that this was a great area of opportunity and was the focus of my start-up.  After a little discussion and debate, I received several emails asking what I was up to.  As promised, here goes...<p>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.<p>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 &#60;requirement&#62;.  We do have the source code (at least someone was thinking).  We want you to get &#60;requirement&#62; to work.  As long as I had the source code, I was always able to satisfy their requirements.<p>I realize that my view may be a little skewed because I only got calls from clients in pain, but in all those years:<p>- I never saw a Class A ERP Implementation.<p>- I never met anyone who saw a Class A ERP Implementation.<p>- I am still shocked by how expensive software and services are.<p>- I am still shocked by how utterly poor the software is.<p>- I am not surprised by how ineffective ERP (and enterprise software in general) is.<p>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.<p>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.<p>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.<p>After living this life for too many years, I have developed several beliefs:<p>- If a business is satisfied with a process, then the software should be made to support the process, not the other way around.<p>- Quality software has an extremely solid base, is well written, and easily maintained.<p>- Good software requires little or no training, documentation, or procedures, and is ALWAYS easy to use.<p>- The current state of packaged enterprise software is almost the exact opposite of everything that I believe in.<p>- Many business people are dying for what they really want while tolerating what they have.<p>- Current web-based technologies (and people like us) have finally made the unthinkable possible:<p>CUSTOM ENTERPRISE SOFTWARE IS THE ONLY WAY TO GO.<p>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.<p>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.<p>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.<p>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.
======
comatose_kid
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.

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

~~~
Kaizyn
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/>

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

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

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

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

------
ajmoir
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 :-

    
    
        Necessary But Not Sufficient by Eliyahu M. Goldratt
        Naked Objects by Richard Pawson
    

From a business perspective I want a group of classes that mirror real world
items e.g. Order, Invoice, Address, Amount, Price, Date etc. Then I want
another group of classes that handle business actions e.g. Enter Order, Print
invoice. Lastly a group of classes that handle business process e.g. Process
Order, Calculate invoice etc.

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.

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

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

~~~
edw519
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>

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

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

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

~~~
edw519
"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.

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

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

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

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

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

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

~~~
edw519
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".)

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

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

~~~
edw519
So then, all I have to do is deliver what I promise, right?

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

~~~
pchristensen
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).

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

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

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

------
Tichy
What is ERP?

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

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

~~~
alaskamiller
For big companies the continued survival is stability in their operating
process. ERP plays heavily into the role of managing large amount of
resources.

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

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

~~~
edw519
Cool link. Thank you.

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

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

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

------
mixmax
If you get the execution right you are headed for greatness :-)

------
pstuart
You are spot on.

------
lvecsey
How about in some way using emacs? The tiger team would develop the elisp
needed to cater to the company.

~~~
sammyo
I so almost distroyed my keyboard with coffee.

Well except I read that there was an emacs macro that business folks at Amazon
used for years. Hmm, maybe if there's an ArcEmacs rewrite?

~~~
Kaizyn
The last thing Emacs needs now is a web server embedded in it.

