@skpatel20,
> If we can't estimate till the AS IS, TO BE and project plan is made, we can't
> quote the client. But after one or two meetings, the client will expect a
> quote and we will expect the order to be closed before we put further effort.
Sure, this is a common issue.
The way we work around this is: first we try to work with "ERP aware"
customers. Our best customers are the one that already know the real price of a
proprietary ERP, otherwise they will tend to highly underestimate the work
required so we would never make it. The customers who compare an OpenERP
implementation with Mantis, PhpBB or Drupal are the wrong ones, better not
fooling you in accepting their deal because they aren't going to make it for
those prices (or you aren't yourself).
Then we try to sale a prototype stage were we have no really fixed goals except
we are committed to do our best to convince we code fast and efficiently (e.g.
they won't misuse their money) and also collect the real requirements so that
we could make a quote after that stage eventually.
That prototype stage might be as long as 1/4 of the overall project. The
longer, the cheaper for the customer (because we then work with trust which is
way cheaper than loosing time over contractualizing more or less obvious things
and making wrong choice since the beginning because we had to make choice
before really knowing). Of course the drawback is that the customer has to
trust you, that might depend on your skills, your company website (go to hell
Tiny ;-), your previous success stories.
Unlike 90% of the other ERP's, OpenERP has a rather fantastic code productivity
for experienced programmers. We can afford that because OpenERP is somewhat
similar to Ruby on Rails coding: it's efficient: so we can always show were the
new features are some hours latter to our customer so that's why prototyping
works with OpenERP. I wouldn't try prototyping with Compiere or SAP, because I
don't think my customer would be satisfied with how little I did alone in one
day, so instead of convincing him that would scare him.
And since prototyping is rather efficient with OpenERP, the same guy (must be a
coding rock star however) can afford being both the prototype coder and the
functional consultant, thus cutting down the costs even more: no need to make
too much friction in over communicating with ambiguous languages between team
workers at early stages. Of course all the polish after the prototype can
eventually be done by some average skilled coder + some less skilled functional
consultant.
The less the customer trust you, the shorter should be that prototype stage and
hence, the more expensive it will be for him, that's for sure. But we can't
really help it, can we?
In some extreme situation were no trust pre-exists, I think we can still make a
quote since the very beginning of the project, but in my opinion we would have
to:
* know more or less the kind of business our customer is doing and know already
how good is OpenERP at doing it natively.
* Nonetheless, before closing such a deal with huge uncertainties about the
real needs, the real native ability of OpenERP at addressing those needs, I
guess we would have to at least double our ideal estimated price and that's
what the customer would have to sign and pay. I mean that's the price of the
risk. Some ERP implementation can really be 3 times the estimated, and that's
with a good open source one...
One thing we might notice is that given OpenERP would typically lead to a 30%
cheaper to a 4 times cheaper ERP implementation, so doubling that ideal price
to work around the lack of trust might cost your a lot of opportunities were
the quote would then be more expensive than a proprietary offer.
Also note that proprietary ERP integrators typically take less risk because
their product is more verticalized already with more features out of the box,
meaning they can even cut the costs (and they do it), they will simply not make
enough money from the deal, but unlike open source integrators relying 100% on
man power, they wont risk to LOOSE money. Large proprietary integrators also
take less risk because they can afford loosing sometimes given that have a huge
mass and they also have good lawyers when needed...
So overall my take on this is: there is lot's of OpenERP demand, only bother to
deal with customers who are ready to assume some risk and accept some prototype
stage. Let the others to the proprietary market or the SaaS market as it fit
better their needs. The more success stories you'll have, the more your
customers will trust you for some prototype and you might enter some virtuous
circle.
Also one final remark: there isn't some magical formula with x new_modules * y
= z the price. Some things that seems really obvious, like keep invoice lines
grouped even if the lines were separated during the shipping for tracking
purposes for instance, are not so trivial to get right, and some good coder
should spend some time discovering what exactly should be done (even if the
solution might be only 30 lines in a module).
The more modules the better because it states what depends on what and cut down
a big issue in small reusable and easily testable and migrable bits. We
typically tend to code some 10 modules per customer, it doesn't has to be more
expensive because we do it right. We so bad integrations mixing everything in
blotaed non testable/migrable modules, those bad practices shouldn't be given
incentives. And we shouldn't be afraid be modules since trivial modules can
dramatically improve the ergonomy at no cost.
What ultimately counts are:
* what is the complexity of the extra features:
* are they only view customization? (basic)
* only report customization ?
* only simple data model extensions + visualization layers?
* overriding of native behavior, then:
* how many methods should be overridden?
* how easy is is to track what should be overriden?
* are all the methods okay to override or are there some tricky methods
that can't be dealt with a super call and should be duplicated leading to sub
optimal code evolution?
* should that overrided logic take new objects into accounts? Then how
hard it is to make the GUI behave nicely with that extended/specialized model
(for instance overriding stock.location and providing sometimes a custom view
of that extended object is NOT trivial, while extending it into a new object
with its own views IS trivial...)
So I mean the devil lies in details, much more than in the raw listing of the
features.
Hope this helps,
Raphaël Valyi.
------------------------
http://www.smile.fr
-------------------- m2f --------------------
--
http://www.openerp.com/forum/viewtopic.php?p=28065#28065
-------------------- m2f --------------------
_______________________________________________
Tinyerp-users mailing list
http://tiny.be/mailman/listinfo/tinyerp-users
