Lets face it...the managers certainly aren't about to fire themselves. You
know the managers old refrain. "Just give me what I want!"
You're absolutely correct here. I'm sorry if my message sounded little bit
confrontational.
Obviously in a work environment you're not there to be confrontational, but
to do the best job possible and help everybody out as much as you can! And
that why you are asking questions here! (this is good!)
Here is one of their reasons;
If Mary creatres a report or a query on HER FE, to deliver info that is
requested by a manager, then when Mary isn't there (away on vacation),
THAT report or query isn't available to them. Therefore Jane has to
recreate the Report/Query to deliver the info to the manager who had Mary
create the report.
I don't know how to counter that argument.
Their is seveal issues and answers to the above. In other words because you
company has a particular user need doesn't necessarily override how you been
deploying all your software applications for the last twenty years. Because
some employee might need to work in an restricted area on occasion at work,
it doesn't mean that you remove all the locks in the building to accommodate
that one request. The old saying about the cure being worse than the problem
comes to mind here.
So the first thing you need to do in that case is to formalize that process
of creating a new report. If a new report is created, then it needs to be
incorporated to the next release of the software that you're going to deploy
to all the users. There are always certain documents and procedures that
need to be followed when certain things in an organization are changed.
This situation should not really be much different. As pointed out by the
other responder, there's also the fact that you can't make design changes to
the application when other users are using that un-split application.
The beauty and advantage of working in an split environment is that you can
have your team of developers and software people (or Mary!) make changes to
the application. It's possible that some of these changes are potentially
giving wrong information, or could even potentially damage the production
data. Most companies don't work on their airplanes while they're in flight
with passengers in them, and often software is the same kind of thing. I've
seen some companies make mistakes in a sales report, and as a result spend
HUGE amounts of money because their access application was giving out the
wrong numbers for sales data. So like anything else, the more important this
stuff becomes, the more formalized and a more serious approach is needed
here.
The other important issue here is often it's better to formalize the process
of having a new reprot built since then you have someone overseeing that
need or the "why" that report is being made in the first place.
I been deploying software for customers for about twenty years now. I will
say that in virtually EVERY single case after about a year, the requests for
additional reports goes down to near zero. They will then run that
application for MANY years without requesting additional reports.
I mean if you have a sales report, it's only to be sliced up by perhaps
employee, sales region, city, and a couple other areas. So, as each new
request comes for reports options, you simply add those features and
filtering options to your report prompt or flter form. If this is done
right, the beauty of this approach means that often that if a new request
for some type of filter reports by a city comes in, then your change in your
software design will work for ALL EXISTING reports you've built for the last
five years. If you don't take this type of approach to adding features then
you'll add one new feature to one report, and the next week every body else
will be asking for that SAME filtering ability to go all the other existing
reports. Next thing you wind up having to spend more time adding new little
features everywhere because you didn't spend any time planning this out in
the first place.
For things like yearly sales data and monthly or quarterly reports, that's
going to be done witth some type of report prmopt system. In other words
it's quite rare that people will need to develop and design their own
reports. Here some screen shots of what I mean:
http://www.members.shaw.ca/AlbertKallal/ridesrpt/ridesrpt.html
Take a close look at the second screen in the above, you can see this been
many options added over about the first year of use.
some options are:
[] include garbage accounts
[] Include key accounts
[] include all new accounts for this year
The list goes on.
There's two very significant issues in the above that bodes very well for a
software development process.
#1 - new users of the application don't have to be taught what kind of
criteria is needed for "key" accounts. They don't have to be taught what
kind of criteria is needed for garbage accounts. In other words this far
more easy and requites far less Training for new employees to use your
application. In other words if you spend some time to build a particular
report, you also ensure that every new employee reaps the benefits of that
new option here.
#2 - Current users don't need to be sent off to some school to learn complex
SQL (which is needed for some of those criteria is in that sample above).
I mean if your employees have to start doing software desing, then you might
as well start also having your employees working on the company truck when
they also have some spare time. In other words you have to question what
kind of training and what kind of software development process you want
these employees to learn in place of YOU providing a solution for them in
order for them to get their work done during the day.
As I said, it is extremely rare for my customers of my products to come back
to me to ask me for reports. Usually after the first few months of running
the application, we pretty much figured out what what kinda criteria and
prompts they need to drive the selection of reports we've built for them.
after that, they're good to go for the next ten years.
So the question becomes; Can the FE be run off of the server?
Well you can do, but it makes the reliability of the software very low.
Worse is users can NOT make design changes when other users are working on
it.
I mean you can ask the question to your mechanics that run the company
vehicles should you change the oil regularly? You don't have to! You can run
those vehicles and trucks untill they breakdown. At the end of the day you
are wasting a lot of money. It simply not a smart way of doing things.
Lets face it...the managers certainly aren't about to fire themselves. You
know the managers old refrain. "Just give me what I want!"
Right but I know of small companies with only about 5-8 computers spending
MORE money on support dollars and more downtime and more problems than some
companies with 25 computers! This is just like running trucks or any other
kind of machinery that you have. If you do it the wrong way you'll be
wasting a lot of money. You not saving any money here.
At the end of the day you been deploying all your other software on each
computer. You can automate the updating process to deploy out new changes to
your software application to reduce the issue of having to deploy new
updates one report a are created. You simply want to formalize how this
process works.
Perhaps you plan to send your employees off to school to learn how to repair
the photocopier. Perhapys you plan to give your staff more lessons on
software design expertise. At the end of the day it's really your choice how
you want to do this.
For about the last twenty years as a general rule we been installing
software and each computer because it works better. Further as pointed out
if one person needs to do design work on the application, then all the other
people must stop working and stop using this application. Can you imagine if
you're modifying word and everybody else goes home because they can't use
their word processing software anymore?
At the end of the day only you can only figure out the consequences of your
actions here. Maybe there's only three employees, and maybe the only the
other two use this application once a month for a few minutes. In this case
you're not going to have much problems in terms of reliability if you allow
occasional users into that same front end.
However if you have several users all the time during the day using that
application, then the frequency of problems will increase dramatically.
There's never one size that fits all here. You might have a company truck
used once a year for the company picnic. Who cares if you change the oil
every few years, it don't matter. In the other hand if you're in the
delivery business, you better maintain those vehicles and trucks very well
or they will eat you alive with huge maintenance costs.
