Re: Request for comments: towards CRM functionality

[Chris Travers <..hidden..>]

A couple comments.

On Mon, Jul 25, 2011 at 10:38 AM, Pete Houston <..hidden..> wrote:
> On Sat, Jul 23, 2011 at 01:52:25PM -0700, Chris Travers wrote:
>> Pete:  Can you define ERP?  Does that include our order/quotations
>> management side?
>
> I can't define it, and it will mean different things to different
> people of course. A quick glance at openerp.com gives this list:
>
>    * CRM
>    * Accounting
>    * Point of Sale
>    * Project Management
>    * Warehouse Management
>    * Human Resources
>    * Purchase
>    * Manufacturing
>    * Marketing
>    * Invoicing
>    * Application Builder
>
> ... so there's a starting point anyway.

The way I look at it is that an ERP is a framework for building
integrated enterprise management applications.  It may come with an
application but ideally that is a point of departure as necessary.

One of the huge issues with the inherited codebase is that it is not
capable of providing any sort of framework of this sort.  You get the
application possibly with some light customization and that is it.

Ok, so why is this important?  Every business operates differently and
has their own ideas of the best ways to do things.  The workflows in
any possible version of LedgerSMB will not suit all businesses.  And
it's better to provide options for being able to customize the
software in a maintainable way.

The way previous versions of LedgerSMB (and SQL-Ledger) have tried to
solve this problem is to be everything to everybody.  As a result, we
are a retail management solution for businesses which have no retail
management needs.  I think we are all on the same page that this is
not really desirable.
>
>> 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.
>
> Is Quickbooks an accountancy package or an ERP package? Perhaps they are
> trying to move into that space and for a proprietary application that is
> probably a wise strategy. "Look, more features!", they can shout. LSMB
> doesn't have the same pressures, however, and I think it's fine (ideal,
> even) that it shouldn't keep adding features into the core codebase
> which aren't there to solve the core problem, which I see as making
> bookkeeping and accountancy manageable for SMEs.

I would argue that accounting is part of ERP and that bleedover
inevitable in this market.
>
>> 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?
>
> Quite. I suspect it's low, but those who do use it probably like it. It
> might be a good case for splitting out into an optional module.

Ok, so in addition, there are some important benefits in doing so.
Point of sale is a wide market with a huge set of very diverse needs.
A POS that works well for a hardware store does not work so well for a
restaurant.

Breaking out retail management functions into a separate project with
its own lifecycle would mean that it would become easier to put
together niche POS's for various specific verticals. You could have a
retail management solution which included a POS and a hospitality
management solution which featured a very different POS.  These could
be thick clients or web apps.

But obviously we can't do this without a rock solid and stable API for
invoicing which has to be done first.

>
>> 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.
>
> Agreed, albeit that order management is more tightly bound to the core
> than the other examples.

Is it?  Orders are not financial documents, while POS sales are invoices.
<snip>

> My concern is that the development time which is spent on these other
> areas is time not spent on the core. Not being on the devel list it
> isn't clear to me how much still needs to be done on the core to make it
> rock solid (which it really has to be before anyone starts building
> modules to go on top of it). Of course the team should plan ahead, but
> if you are considering this wider functionality now, the question is: is
> the core and the API ready for it?

For 1.3, the areas in core which are API-ready are limited in part
because we are developing the API specs still.  They include:
1)  Payments and receipts
2)  Reconciliation
3)  Fixed Assets (Depreciation and amortization)
4)  Contact/Vendor Management

Post 1.3, there may be some changes to the API framework to
accommodate some issues found with our approach, and the API's of the
above may be slightly adjusted.  I also want to add:

AR/AP/GL, and basic financial reports.  That will cover core.  Work is
partway complete for this.

I would also like to put out reference implementations of the database
interface for PHP and Python users.  This isn't a lot of work, but it
could substantially improve the size of our community regarding the
database-level API stuff.  Ideally these would become the basis for
other interfaces maintained by others.

The second thing is that the nested projects as crm tickets is not
something that I would expect to add significant effort at present
over what's needed to get projects into a new API-friendly codebase.
We have to rebuild this code anyway.  We might as well look at how to
do it with as much flexibility as possible.  That leaves appointment
tracking which someone else could do or else we could do it, but
probably won't be in 1.4 unless someone finds that it is important
enough to fund development.

>
> Looking at 2 very successful projects with which I am familiar - apache
> and perl - both have a highly modular approach with modules being
> contributed from both the core dev teams and the wider communities.

That's what we are shooting for.  In fact ideally each of the optional
modules would be a subproject with its own community and contributors.

>My
> belief is that they have been successful in using this approach because
> of the time and effort spent on the core and the API to begin with. If
> LSMB is going along the same path then I will be very happy with it.

I think we are on the same page here.

Best Wishes,
Chris Travers