[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Reporting activities
There are two capabilities (at least) that cover the
reporting of activities using Activity_actual, Representing_activity and
Representing_work_done. When working with templates in this area, I’ve
found that there is reason to separate two types of activity reports, for
maintenance activities and operational activities. Theoretically we might need
something for design (or production) activities as well, but I don’t know
how far we should take this. Activity_actual’s for maintenance always have a relation
to directed_activity, they have inputs (PAI or PAR) and sometime outputs (PAR).
It is sometimes important to see the status of the activity, i.e. how far into
completion is it. They may also be used to track configuration changes. They
typically have both a start_date and an end_date, but the end_date must be
optional. A Directed_activity has an Approval, but an Activity_actual does not
(it is a report of what was done). Activity_actuals probably have a responsible
or executing organization assigned to it, and it may be further characterized. Activity_actual’s for operation may have a relation to
a planned activity, but not to a Directed_activity (which always is accompanied
by a Work_order). They always have a relation to one product (PAI), which is
the product used, and there is no input or output. They have at least a
start_date, and optionally an end_date. An operational Activity_actual could
have an Approval assigned to it, if the usage of the product requires an
approval. However, I would prefer to assign the approval to a planned Activity
in that case (using Activity instead of Activity_actual). The biggest reason for separating out maintenance from
operation is however that business people work in either domain, and they have
probably difficulties in understanding how a generic capability should be used,
if it is explained to cover both aspects. I propose to do the following, based on the above: 1. make sure that capability Representing_work_done is
described as valid for Maintenance (and design), and develop the template
representing_work_done. 2. Make sure to make distinctions in cap
Representing_activity between Maintenance activities and Operational
activities, and rename the template representing_activity_actual into
representing_product_usage, and pointing to repr_work_done for maintenance (and
design) activities. 3. Develop a template representing_planned_activity within
cap Representing_activity based on entity Activity, that covers the needs for
operational planning of activities where no Work_order is used. 4. Develop a template representing_typical_activity within
cap Representing_activity based on entity Activity_method, to meet the business
requirement to be able to set up typical activities or missions within operation.
This would be similar to ‘tasks’ for maintenance activities. Before I do this I would like to have your input on my
thoughts, especially from projects with operational needs. The alternative to
the above is to make generic capabilities and templates that covers both
design, maintenance and operation, and I think they would be quite complicated
to sort out. Peter This message contains information that may be privileged or confidential and is the property of Eurostep Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]