From your description, it sounds like you are asking if your Access table(s)
should look like a spreadsheet.  You can do that, but you won't get much
advantage of Access' relationally-oriented features and functions if you
feed it 'sheet data.

If you are not familiar with the topics of normalization and relational
database design, there's a steep learning curve in your future before you'll
be able to make (full-er) use of Access.

If you ONLY need to use Access to report on data, could you simply link to
your Excel spreadsheet itself and generate the reports?

Regards

Jeff Boyce
Microsoft Office/Access MVP

The general rule is one issue/question per thread but your concern
about your capacity to design your own application properly is worthy
of response so I'll address it first.

   Create your application flawlessly on the first try?  Absolutely
not.

   Create your application with a lot of trial and error, more posts
to the newsgroups and lots of offline reading?  Absolutely true.

I can see why Jeff thought you were doing something in Excel even
though you expressed Access and never once said "Excel"

You need to learn about Normalization and then learn to apply it to
your designs religiously.  Go visit www.mvps.org/access and search for
"commandments".  Those commandments really spell out a few issues.
That is a terrific site for Access developers.

This newsgroup and ...gettingstarted are the two best ones for novice
Access developers.

As your analysis of what your application is going to do progresses
you should be able to identify most of the entities in play in it.
All entities of a given type belong in the same table.  That table is
usually given a name like the singular of the entity type because that
is what each record is really about.  For example if I'm dealing with
People, I'll define a "tblPerson".  Your preferences and mileage may
differ.

Once you start the actual design process you'll discover a lot of new
entities.  Often these new entities are simple attributes of other
entities:  Colors, for example.  Why type out vermillion each time
it's needed?  Create a table tblColor and list all of your colors in
it.  When you need one, select it from a combobox that shows all of
the colors.

Some entities that I think you need:

tblEmployee
   EmployeeID    - Autonumber PK
   EmployeeLast    text    Break out the names as
   EmployeeFirst    text    shown.  You can always
   EmployeeMidle    text    concatenate to display.
   EmpID                 text    Employee number
   DepartmentID    Long Integer - Foreign Key
   EmpSuervisor    Long Integer - Foreign Key to supervisor
       record in this table.  Implies that you enter bosses first.

tblDepartment
   DepartmentID    - Autonumber PK
   DepartmentName    text
   DepartmentDescription    text
   etc.

tblAudit
   AuditID    - Autonumber PK
   AuditName    text, number, ??  Don't use an autonumber
   AuditDate    Date/Time
   AuditNote    text

tblAuditEmployee    Many side to Employee on the One side
   tblAuditEmployeeID    - Autonumber PK
   EmployeeID    Long Integer Foreign Key
   AuditID            Long Integer Foreign Key
   WorkID    Long Integer Foreign Key into tblWork - what is
                   being audited??
   Quality    integer    value returned from option group

   Note that there can't be an average on a single record with a
single value.  You can generate that kind of information in your
reports....

   If you intend to track several different "things" per audit then
this structure has to expand.

   No attempt was made to demonstrate tblWork.  It's just that you
have to identify what the audit is all about.  If the same audit will
be applied to the work of several employees on the same day you can
resolve which data belongs in which table.  If the data is exactly the
same for all elements at a single level then it probably belongs in
the level above.  If it *can* change between records at a given level
then it must be changeable at that level.

HTH