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

Re: Clear competitive advantage



Hi Bob;


On Sat, Aug 3, 2013 at 2:06 PM, Bob Miller <..hidden..> wrote:
Hello,

> Although I understand you're asking these questions, it'd be extremely
> interesting to know why people choosing other solutions did *not*
> choose LederSMB: after all, maybe their choices are based on missing
> bits in our image / communication. The answers you're going to get
> from this list are probably going to re-inforce the current
> communication.

I can answer this question, at least as it pertains to my customer base
and geographic area.  I have tried (mostly unsuccessfully) to sell this
accounting system for a long time, and where I have succeeded, everybody
has moved away from it afterwards.  The base reason shows right here in
this thread - none of the answers about why we use lsmb contain a
"because it is simple and easy to use".

Just to be clear, one difficulty here is that such a criteria requires a pretty clear target audience.  What is simple for one business to use can add needless complexity to another.  This is a significant problem and it is something that I think has to be tackled first by having a flexible framework in place and then secondly working with customers to address their issues.  I think long-run we will beat them at this.  Short run, it is a challenge.

But there is another problem here you are right to bring up, which is that usability requires a lot of thought as we redesign pieces of the system.  Additionally this means we may get something in which requires refinement.  But things are getting better, I think.  The 1.3 reconciliation screen may look more complex compared to 1.2 but it is a much better match for actual reconciliation workflows.    I think just about all aspects of the legacy code need significant changes from this perspective, ranging from the menus to the the actual data entry screens.

One of the real problems is that SQL-Ledger's approach was to try to be everything to everybody, while our approach is to try to be anything to anybody.  Long run, I think one of the key expectations to set is that customization pays off and it always will.  Hopefully as we go further, it will pay off more because costs for customization will go down and so it will be possible to better match one's ideal business processes for less.  Short-run there are plenty of areas where it is more necessary.

In my area, Sage Simply Accounting is probably in use by about 90% of
the businesses (yes, 90%), of the remaining 10%, probably about half use
quickbooks or other Intuit software, and the rest use industry-specific
or mac-oriented software.  Probably the biggest single reason for that
is the accountants in this area; many of them won't look at your data if
you don't give it to them in such a way they can drop it into simply
accounting.  If an accountant will take it, often you have to pay them
to convert it, which usually means paying them to manually re-enter all
the data into Simply - needlessly expensive.

That might be a good use case for hosted solutions, and an ability to grant an accountant access for a period of time and then disable the user.   Why import when you can access and suggest adjustments (in a  batch or other unapproved transactions) live?  Again though usability would be a key there.

In addition to that, Simply Accounting just looks after so many things
where in lsmb the workflow is complex.  1 example of many; charging
interest on overdue accounts.  in lsmb that is a prohibitively complex
chore, in Simply Accounting it is ticking a box.  

That has been on our todo list for a while.  It is not a huge priority absent paid work right now because it ill be simpler to do once we re-engineer invoices.
 
Simply Accounting also
won't let you make an obvious mistake.  If you try to do something
stupid, it will stop you.  As I am sure we have all dismayed at one
moment or another, lsmb happily lets you do whatever stupid thing occurs
to you at the moment.  Several times in a row if you insist ;)

Could you give some specific examples?  Defining "obvious mistake" is hard and examples make it easier.  Just to let you know we have tightened up certain sorts of controls for certain kinds of obvious mistakes here during 1.3 and are working on tightening up some more, but examples are really important to get so we can decide how to differentiate them from legitimate but very similar workflows.

I use lsmb for two reasons: 1. I am militantly open source - no
proprietary software on my network.  2. ~5 years ago a customer needed a
POS system, and lsmb was the best option at the time so I learned it
well enough to deploy it, and now I am sticking with what I know - I
haven't looked around or investigated changing in a long long time.
Neither one of these reasons is valid to so much as one of my customers.

My customers won't use lsmb for three reasons: 1.  Why spend money and
time learning to change when there is already a working system that just
about anybody you hire is going to know because everybody around here
uses it.

That's a big one and it is a very valid reason.

 
 2.  Their accountants will refuse them service or charge them
unreasonable amounts of money if they don't use simply accounting.

We need to work with accountants then and reach out to them.
 
 3.
Simply Accounting is to dummy-proof and feature-rich not to use when
compared to lsmb.

And we are missing important little things like payroll in 1.3. 

For your average business owner around here, it is just easier and
cheaper to use Simply Accounting.  They take the path of least
resistance, and lsmb doesn't provide that.  If lsmb did provide that,
there would be incentive to change, and I think people would find other
accountants, or pay their accountants the extra money to convert it, or
the accountants themselves would start to take lsmb more seriously and
support it.



This said, I have been in this industry long enough and followed enough
projects to know that software development is actually a very long-term
process.  Software usually requires a great deal of maturity before it
becomes mainstream, sometimes it takes more than a decade before it can
float to the top, and lsmb isn't there yet.  Over the years I have seen
lsmb gaining that maturity, for example this thread is contributing to
it now.  I have every confidence that over the next years, after the
core is restructured how Chris and the other developers want it, lsmb
will be middle-aged, and those features the end-customers require for
adoption to be considered will rapidly start to surface.  So I wait
patiently and confident that one day lsmb will be an easy (or at least
easier) sell to my market...

that's what we are shooting for.

Best Wishes,
Chris Travers 





------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-users mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users



--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.
http://www.efficito.com/learn_more.shtml
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-users mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users