SQL - simultaneous GC access ? << the need for an "analyst" >>
Mike or Penny Novack
mpnovack at mtdata.com
Mon Jan 4 11:12:54 EST 2016
On 1/2/2016 10:06 PM, __ wrote:
> 4.) is there any plan to regulate access to certain parts of the accounting
> to certain users? (for example a merchandiser being able to make supplier's
> bills but not being able to access/see salaries)
I am going to use this apparently reasonable request to explain what a
"business analyst" does and that "end users" need one in order to
properly frame their requests.
A business end user knows his or her business and may have a very good
idea of the business needs at the business level. But a the same time
might have a poor understanding of how that might best be implemented
(at the business level). In other words, ask for specific changes at the
application level not realizing that these changes would NOT provide
what is actually being asked for. This request is a perfect example, so
I will analyze it to show you what I am talking about.
Let us assume for just a moment that the gnucash application COULD do
this (restrict users to specific accounts). WOULD that prevent a
"merchandizer" with just access to the accounts necessary for his or her
job from being able to obtain salary information? << does NOT have
access to any of the payroll accounts >>
The answer is NO. Not if the same checking account is used for checks
paying for merchandize purchases and checks paying employees. Do you see
why? And BTW, that's how the analyst gently points out to the business
client the problem, by looking at the situation, seeing the hole, and
asking the right questions.
OK then, need separate checking accounts, no big deal << or maybe
"merchandizing" only produces vouchers, doesn't actually cut checks.>>
But then, is that change to the application really necessary? Well maybe
not. The usual method in the larger business world is "subsidiary
books". And this makes sense, because the CEO or Directors aren't going
to be interested in seeing each low level transaction but the totals. In
other words, the Treasurer (and his or her staff in a large operation)
can access all the books and maintain the "general ledger" which mirrors
the nets of the subsidiary books. But in each area of specialization,
the employees doing that work can only access the subsidiary books of
their area. That needs just security at the file level, and gnucash in
effect has that right now << well it's at the operating system level >>
Look, before retiring, this is what I did (at one of the world's largest
"financials"). Besides analyzing at the system level (estimating the
effort to fill a client request, designing the software, etc.) user's
planning their requests could ask one of us analysts to sit in an help
them frame their requests so if they got what they asked for it would
actually do what they wanted and not be useless.
So what I am saying is that if you have a "business need" (that can of
course be for personal accounting too) ask at THAT level instead of
making requests for specific changes at the application level which
might or might not have the desired end result. To go back to the
specific example, might have been "can we have something so that workers
in some sub section of the business ("receivables", "purchases",
"payroll", etc. ) can only see that part of the overall business system
that they need to into order to do their job". But not making that
request at the specific change to the application level (security at the
account level).
Michael D Novack
More information about the gnucash-user
mailing list