[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Request for comments: towards CRM functionality



Just an interesting aside to this. The last time I put a largish customer into one of these systems (it was SQL-Ledger, as this was soon after the fork), one of their first questions to me was: how can we do contact management and appointment tracking?--our sales guys really need that. My answer: you can't.

They eventually decided to stay with Quickbooks. That wasn't the only reason, but it was definitely a part of it.

Right or wrong, this CRM and ERP functionality is expected behavior now. If you do some of it, you are expected to be able to do all of it.

I agree with using existing solutions as much as is practical, but however it's done, we do need to do it. If that ends up being wheel reinvention in-house, instead of absorbing or linking to something from the broader open source world, then while it may not be the most ideal solution, it will be one, and like it or not, we do need it.

Jmo,

Luke


On Sat, 23 Jul 2011, Chris Travers wrote:

On Sat, Jul 23, 2011 at 11:43 AM, Pete Houston <..hidden..> wrote:
I would tend to agree with Bob on this one. If the development of LSMB
concentrates on making it the best at what it does (which is accountancy
first and foremost with hooks into inventory, PoS, etc.) and then builds
a solid, consistent API on top of that then I would consider that as job
done.

Those who want to add in various CRM, ERP, RT and who-knows-what-else
functionality can then choose their preferred CRM, ERP, etc. tool and
just write the glue to go between them. This is the open source way.

Pete:  Can you define ERP?  Does that include our order/quotations
management side?

Part of the issue is that accounting as a software discipline is
becoming as subset of ERP as a general discipline (as is CRM btw).
Even Quickbooks offers features which are more traditionally ERP
functions than accounting functions.

One of the current issues with the codebase (which is relevant to your
concern) is that it is currently a bit of an
everything-and-kitchen-sink approach already.  I mean, how many of the
users are using the POS functionality?

There are two reasons to look at extending LedgerSMB with modules to
support additional areas:

1)  It provides additional functionality out of the box that is
tightly integrated to the accounting side.  So for example one can do
management accounting based on CRM data (labor cost tracking per sales
rep per sale, etc and apply this both forward looking as well as
backward looking) which is hard to do in loosely tied systems without
adding a lot of really thick glue.

2)  It provides a model for integration with other applications.  So
if you don't like the CRM approach, it becomes easier to push data in
from a third party FOSS app, such that the benefits of #1 are
preserved.

Please don't add in features like this which don't really belong in an
accountancy package and which are implemented well elsewhere - just give
us the tools (ie. an API) so that our choices of applications can be
made to talk to one another.

TBH we are already to that point.  A POS interface, quotation and
order management, etc. are all things which probably belong more in a
larger ERP framework than in a accounting program narrowly defined.

So what I would like to see is something for 2.0 that gives us all a
benefit from both worlds.

1)  A core module (basic contact/credit account tracking, chart of
accounts, AR/AP transactions, GL transactions, financial reports.  No
inventory tracking, no quotations and order entry tracking.  Just a
solid, very basic accounting module.

2)  Other modules around this which provide additional functionality.
Areas which would be moved into optional modules would be:
a) Job costing and project accounting.
b) POS and retail management
c) Inventory, Warehousing, Invoicing, and Order Management
d) Pricegroups
e) Departments and budgets
f) Assemblies and manufacturing
etc.....

The thing is, I don't think we can get to some of the more advance
possibilties in accounting (management accounting in particular)
unless there is a model for tracking CRM data in a more
management-accounting-friendly way.  So what I am looking at first and
foremost is a way of extending the job costing side to make it more
CRM-friendly.

I do agree that if someone doesn't need something they shouldn't have
to install it.  A point of sale aimed at small retail shops doesn't
make ANY sense when installed at a financial services business, for
example.  Ideally each of these would be separate projects integrating
at the database level.  But we aren't there yet though I'd like us to
be there by 2.0.

Also as a call to the community, if there are other things you want to
see available as addons and are willing to put code into, we do have a
separate area of SVN (for 1.x) set aside for this.

So I don't entirely disagree with you.  I just don't want to see us in
a corner because we focus on financial accounting to the exclusion of
other (higher end) forms of accounting which pretty much require wider
functionality to work.

Best Wishes,
Chris Travers

------------------------------------------------------------------------------
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide.  Store less, Store more with what you own, Move data to
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
_______________________________________________
Ledger-smb-users mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users