Each function defined in the previous activity is
associated with at least one "object" it must work with or
manage. Objects represent the facts and events needed to manage
corporate resources. Factual objects include such things as
personnel, money, equipment, parts, products, vendors, data,
etc. Event related objects consist of such things as billings,
orders, shipments, transactions, etc.
"Objects" are represented using File Descriptions (FD). In Data
Base Engineering terminology, these "objects" represent
Application Logical Data Base Models (ALDBM). Because of these
data base considerations, Data Engineering is used to locate
existing "objects" and/or prepare new ones. However, it is not
the intent of an EEM project to prepare a complete data model
of each "object"; this is reserved for DBEM. All that is
required is at least a basic description of the object and
the primary "basic grouping" data element used to identify the
"object." For example, the "Customer" object will use the data
element "Customer Number" to uniquely identify it; the
"Employee" object will use the data element "Employee Number" to
identify it. Perhaps the best way to think of the "primary
basic grouping" is as the key for the logical file. One way to
test for the existence of an object is to verify that a data
element is used to uniquely identify the object. If a data
element does not exist, then you probably do not have a valid
object.
With the relationship between functions and "objects"
established, Enterprise Engineering defines the information
requirements for each function as they pertain to each "object." There
should be considerable attention to detail during the
definition of information requirements. Enterprise Engineering
must consider:
- "What" must be known about each object in order to perform
the function effectively.
- "What" actions and/or business decisions will be performed
based on the information received.
- "What" benefits, both tangible and intangible, the function
will receive from having the information.
- "When" the information is required in order to receive the
maximum effect.
There should be at least one information requirement per
"object."
Enterprise Engineering then prepares a formal description
of the information requirement including:
- Which function(s) will receive the information.
- The timing of the requirement (frequency, offset and
response time).
- What type of function the information serves (policy,
control and operational).
- A written description of the requirement with sections
for:
- BUSINESS PURPOSE - (to accomplish what?)
- ACTIONS AND/OR BUSINESS DECISIONS - stating WHO
will use the information and HOW.
- BENEFITS - both tangible and intangible.
- The primary "basic grouping" data element of the
object(s) affected by the requirement.
Enterprise Engineering also cross-references the existing
systems, if any, to the functions and information requirements
they support. This will be used for analytical purposes in the
next activity.