Access Bulletin Board? Acess/Excel Jobs?

[David Portwood]

Just wondering if anyone might know of online resources providing info
pertaining to Access or Excel software positions. How does a person go about
finding such positions? CareerBuilder, Monster, HotJobs? Is there someplace
more specific? Is this the kind of thing that generally requires referral?

 

[Larry Linson]

Just wondering if anyone might know of online
resources providing info pertaining to Access or
Excel software positions. How does a person go about
finding such positions?

There seem to be fewer jobs, these days, with requirements for _just_ Access
or Excel. Most require a broader knowledge of software, depending on the
type of job -- the requirements will differ for a job as an "information
worker" (primarily end-user) or as a developer (preparing developed
applications for other users).

The "best candidate" is usually considered to be one whose knowledge of the
tools used is excellent, but also has experience and ability in the business
of the employer or client company.

CareerBuilder, Monster,
HotJobs? Is there someplace more specific?

These and other online job services list such jobs. Local recruiting firms
often are looking for employees for their clients to hie, and some of them
are looking for subcontractors or temporary employees to work on contracts.

Is this the kind of thing that generally requires referral?

It is always helpful to have a personal endorsement, or personal
acquaintanceship, with someone known to the person who has a job. That's
why I recommend any technical professional looking for employment seek out
and join appropriate professional associations and user groups. Contact
people you know who might have contacts and ask for their recommendation or
referral -- the online professional/technical networking services could be
helpful, too.

Larry Linson
Microsoft Office Access MVP

 

[David Portwood]

There seem to be fewer jobs, these days, with requirements for _just_

Access or Excel.

The place where I am working now has a great deal of common data floating
around in a disorganized mess. It seems that every rep/analyst in the office
has their own amateur Excel spreadsheets which they spend many hours each
week updating to provide - at best - imperfect information.

Of course, each person thinks his spreadsheet work is marvelous and they
guard it jealously. This causes other problems. For instance, if Anne has
data needed by John, but Anne is out of the office for some reason, John is
out of luck. Worse, John may not know that the person sitting across from
him has the data he needs, so he spends many hours recreating data that
already exists. Etc.

It seems to me there is an obvious need for someone to pull things together,
to create and maintain a centralized, well ordered (normalized) database of
common data and from this database develop specific applications to improve
productivity in the office using the standard MS Office products: Excel,
Access, Word, Outlook, etc.

However, what seems obvious to me is evidently not so obvious to management
in my office (where I'm currently a contract clerical temp). I've heard the
term "Enterprise Programmer" used to label the function I've just described
but my office has no such position on its books.

I'm certain there are other offices that do recognize such a need but I'm
not sure how to go about finding them.

Well, that's enough whining for one holiday weekend. Thanks for the reply,
Larry.

 

[Tony Toews [MVP]]

The place where I am working now has a great deal of common data floating
around in a disorganized mess. It seems that every rep/analyst in the office
has their own amateur Excel spreadsheets which they spend many hours each
week updating to provide - at best - imperfect information.

Of course, each person thinks his spreadsheet work is marvelous and they
guard it jealously. This causes other problems. For instance, if Anne has
data needed by John, but Anne is out of the office for some reason, John is
out of luck. Worse, John may not know that the person sitting across from
him has the data he needs, so he spends many hours recreating data that
already exists. Etc.

It seems to me there is an obvious need for someone to pull things together,
to create and maintain a centralized, well ordered (normalized) database of
common data and from this database develop specific applications to improve
productivity in the office using the standard MS Office products: Excel,
Access, Word, Outlook, etc.

Excellent thinking. And I would agree with you. One technique one
person used was, when attending various meetings, look for reports
that didn't have an alternate grey bar. (The ERP system produced the
Access reports with an alternate grey bar.) So he'd ask the person
what they needed and we'd do the work to get them to use the new
system.

Then we started added lots of functionality but that's another story.

I was told by the manager of the office where I was working on such a
system for over two years that every month they paid me I saved them
that money that month alone. Let alone subsequent months. He is

However, what seems obvious to me is evidently not so obvious to management
in my office (where I'm currently a contract clerical temp). I've heard the
term "Enterprise Programmer" used to label the function I've just described
but my office has no such position on its books.

Well, that sounds like a high falutin' title to me. Whoohoo. But
that job does need
1) an executive champion who will get folks thinking in terms of
common, accurate data.
2) someone who can effectively deal with the users to find out their
requirements and figure out solutions
3) someone who has a good deal of database and Access experience who
can build such a solution.

Sometimes 2 & 3 can be the same person for exceptional individuals.

I'm certain there are other offices that do recognize such a need but I'm
not sure how to go about finding them.

Yes, that's going to be the tough one.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Larry Linson]

"Enterprise" is a term often used to describe a very large ("humungous"
might be a good description) organization. I'm not familiar with the term
you describe, though, and am reasonably sure there's no agreed definition
for such a position in the "industry". I have been a programmer in
"enterprises", but no one in the enterprise held that title. I've also been
a programmer working with "establishments", typically, considered to be
businesses somewhat smaller than enterprises.

Yes, you would need to convince someone in management to sponsor such a
project, though I've seen some "guerilla operations" where a manager over a
small portion of a greater organization would decide that he/she had to get
a handle on data in that area. The resulting database could, if well done,
attract others to say -- can we get in on that?

A global corporate/organizational database is a pretty ambitious thing to
use as a starting point. Maybe you can convince some "lesser manager" to
give a smaller one a try. Many spreadsheet data repositories are candidates
for a database, but certainly not all of them are.

Good luck with your efforts

Larry Linson
Microsoft Office Access MVP

 

[David Portwood]

A global corporate/organizational database is a pretty ambitious thing to

use as a starting point.

Not "global corporate". The company where I work already has corporate IT
people maintaining corporate wide applications. But within a particular
branch office the reps are on their own.

Perhaps the theory is that the corporate applications should be all the
software support that anybody needs. Or maybe it's just a matter of not
being able to afford field level IT personnel. Not good managerial thinking.
As Tony mentioned, the potential for savings and/or increased productivity
should far outweigh the cost, if the right person is doing the job.

Finding the right person might not be so easy, and of course the wrong
person might do considerable damage. Many people know how to code Access
commands, but designing an appropriate software solution is quite a bit more
than that.

A long time ago I worked at Hughes Aircraft as a software engineer. At
Hughes, lower level engineers coded the designs that the top level engineers
drew up for them. The top level engineers didn't even need to know the
specific language in which the project was coded. My point is, knowing what
to do is far more important than knowing how to do it.

Enough. Gotta go get my brakes fixed, if I can find a place open on
President's Day.

Thanks for responding, guys.

 

[Terry Kreft]

Not really, if you know what to do but don't know how to do it you are just
as useless as if you don't know what to do but do know how to do it.

You need both parts for the job to get done.

I think your aside about your brakes nearly illustrates this.

 

[David Portwood]

Not really, if you know what to do but don't know how to do it you are

just as useless as if you don't know what to do but do know how to do it.

I disagree. I probably didn't explain myself properly. I'm thinking of
programmers who know all the language tricks but nevertheless end up coding
impressively complicated "square wheels", i.e., solutions that seem to work
but are not really a good fit at all. We had quite a few such engineers at
Hughes. Many of them went on to managerial positions.

The problem is, a square wheel does work, and if the end user has never seen
a round wheel, he can often be convinced that a particular square wheel is
really a marvelous product.

About a year ago I proposed an Access application to replace a system of
Excel workbooks to my boss. At that time I knew little about Access,
although I do have a programming background and a Master's in Computer
Science. I knew what to do, but didn't yet know how to do it.

So I got an Access textbook, pulled code from examples in the text and -
admittedly with more than a little help from this group - eventually
completed a fully secured, split, multiuser app which included my own auto
FE updater applet and also an Install applet. No square wheel, I do solemnly
swear.

During the design phase I was constantly rebutting my boss' attempts to
meddle. She is something of an Excel guru and considered herself well
qualified to lead the Access design effort. She refers to herself as a
"numbers girl". Some of her design ideas all but gave me nosebleeds.

Left to her own devices, she would have created a square wheel, not because
she didn't know how to work with Access, but because she doesn't understand
what comprises good design. So I basically said yes to everything she
suggested/ordered and then did it my own way.

A loose analogy: an English teacher who knows everything there is to know
about conjugating verbs and such, and yet somehow his novel turns out to be
trash.