Implementing Engineering Change Order (ECO)

Responsibility = Manufacturing and Distribution Manager

1. Navigate to the Engineering Change Orders window.
!N" Engineering # ECOs# ECOs
$. %se &11 to start a 'uery.
(. Enter the following data)
* ECO Nu+ber = ,enter the ECO nu+ber you wish to 'uery,
-. %se Ctrl &11 to run the 'uery.
.. !M" /ools # 0+ple+ent !1" 2es
3. Ensure that the re'uest is co+pleted.
!M" 4iew # Re'uests
4iew the co+ponents on the pri+ary 1ill of Material
5. Navigate to the 1ills of Material window.
!N" 1ills of Materials # 1ills # 1ills
6. %se &11 to start a 'uery
7. Enter the following data)
* 0te+ = ,!88 1999*%ser Defined 0te+ Nu+ber",
19. %se Ctrl &11 to run the 'uery.
1
11. :elect the ECO tab to view the change order.
1$. Close the window.
2
Oracle ECO Approval process and shortcomings
With the environment of a company becoming more and more dynamic, the pressure on
engineering processes to accommodate for changes is ever increasing. For such changes
to yield engineering efficiencies, an arrangement can be formulized whereby they cannot
become effective until a responsible agent releases an Engineering Change rder !EC".
#eing an essential component of Engineering Change $anagement, an EC is a written
document authorizing to incorporate changes in the scope of the engineering process. %n
EC specifies changes to one or more items that are logically related to each other, such
as a new product introduction, changes to #$ structure of an assembly item,
component item revision changes and so on. &n oracle E#' system, each EC specifies
changes for one or more revised items and each revised item change can be associated
with one or more of its corresponding revised component changes. (epending on the
EC type, an EC can be enabled to revise)update only manufacturing items and bills, or
be enabled to revise)update both manufacturing and engineering items and bills. %n EC
can update prototype and)or production routings too.
Every EC needs to be approved before it can be implemented in real*time. 'tandard
functionalities of the racle E#' support manual maintenance of static approval lists for
this purpose. +he Engineering change order processes involve wor,flow based and non*
wor,flow based approval methods. When the EC is submitted for approval through a
standard E#' wor,flow, the approvers specified in the static approval list receive
wor,flow notifications or email that the corresponding EC is awaiting their approval.
+he static approval list comprises of a set of active employees !recommended to be apps
users" in the system designated as %pprovers, represented by an approval list name. +he
list-s name is the identifier referenced on every EC while the approvers of that list are
the identified sta,eholders for approval of that document. (epending on the EC type
and priority, one of the seeded approval wor,flow processes is chosen on the EC based
on the application module setups. (epending on the logic of the wor,flow process being
selected, the analysis of approval is performed based on the responses provided by the
approvers of the static list. .pon completion of this vote analysis process, the EC is
considered %pproved or /e0ected and its status changes accordingly. nly an approved
EC can be implemented.
+he advantages of this standard E#' methodology are the ease of control and reduction
in system comple1ity. %lso, the number of approvers in each approval list is unconfined.
2owever, the downside to this approach is that even a minor change of adding a new
approver to the approval list re3uires creation of a new approval list because, any change
to the original approval list would affect all ECs referencing the same*which may not
always be necessary. %lso, the addition and)or removal of approvers from)to an e1isting
approval list is a manual tas, involving a lot of intra*organizational communication and
involves considerable time and effort in this decision ma,ing. &n essence, the revised
items and revised components on the EC and their nature determine the approvers for
that Engineering change. %n automated approach of maintaining a system generated EC
specific approval list is dealt in my whitepaper.
4
%pprovers of an EC are the sta,eholders who are directly or indirectly affected across
the supply*chain due to the proposed changes for the respective items being revised by
that document. +hese sta,eholders normally include #uyers for purchased components,
&ndustrial Engineers, 5lanners, 6uality Engineers, Customer 'ales representatives and
other sta,eholders of the management committee. +hough not all items being revised on
the EC directly affect all of the above mentioned types !groups" of sta,eholders, the
changes proposed for these items can trigger the alteration of the nature of other related
items of the supply chain that eventually re3uire action from their respective
sta,eholders. For E1ample, when a raw component item undergoes revision change, it
can affect the finished assemblies !which uses the component item" being manufactured
by the organization and)or may mandate 3uality compliance testing to adhere to the
industry standards and)or may re3uire advanced planning of all other raw materials along
with the revised item in order to cater to the upcoming customer demands and)or to
manage customer e1pectations based on the ultimate results)effects of the EC.
&n the E#' system, the identification of approvers for every EC depends on the #ills of
$aterial !#$" of every EC revised item or the revised component. Every item being
revised may either be 7$a,e8 or a 7#uy8 item depending on whether it is the assembly or
the component of the #ills of $aterial respectively. For every EC revised item, there is
a need to identify its full product e1posure at all #$ levels to identify all other affected
items relating to the revised item. For each of these identified items, the responsible
sta,eholders or approvers as described above are to be identified manually and added to a
new approval list. For instance, even in an EC comprising of 0ust 2 revised purchased
items 51 and 52 which are raw components of a single level #$, the minimum number
of affected items would be 51 and 52 and the parent assemblies of these two. +his totals
to minimum of 9 affected items, each of which may determine at least 1 sta,eholder each,
directly or indirectly affected due to the revision changes on that EC. &n such a case,
each of these individual sta,eholders is to be added to the static approval list on the EC.
+his is a time consuming process and redundantly increases the cycle time of
implementation of the Engineering change. $oreover, the number of such static lists
grows by time due to the volume of ECs being implemented in the organization, thus
eventually increasing scope for errors and chances of delays.
%ccording to an automotive manufacturer organization in $ichigan, .'%, the
Engineering change coordinators spend anywhere from 4: minutes to 2 hours for every
EC in identifying all re3uired approvers who need to be included in the approval cycle
depending on the EC comple1ity.
+he focus of my white paper is to automate this tas, of sta,eholder identification within
the E#' /12 environment and reduce this effort to mere mouse clic,s.
5lease let me ,now if anyone would be interested to learn more about my approach and
access my white paper and source*code in relation to accomplishing the same.
9
Oracle Engineering - Setup steps
Step 1: Set Profile Options (Must)
'et the Engineering profile options for
a" E;<= Change rder %utonumbering > 'ystem %dministrator %ccess
b" E;<= EC (epartment
c" E;<= EC /evision Warning
d" E;<= Engineering &tem Change rder %ccess
e" E;<= $andatory EC (epartments
f" E;<= $odel &tem Change rder %ccess
g" E;<= 5lanning &tem Change rder %ccess
Step 2: Enter Emploee (Must)
(efine employees for your organization. EC re3uestors and approvers must be defined
as employees
Step !: "efine Change Order #pes (Optional)
?ou can assign a change order type to your ECs, either using the -EC- change order
type that racle Engineering provides or choosing a change order type from any number
of types you define using your own terminology, such as (esign /evision,
$anufacturing Change etc
Step $: "efine ECO "epartments (Optional)
?ou can group users that use the engineering change order !EC" system through EC
departments, creating multiple EC departments within your &nventory organization.
Step %: "efine Autonum&ering (Optional)
?ou can define customized autonumbering !for a user, organization, or site" for new
ECs or mass change orders
Step ': "efine Approval (ists (Optional)
?ou can define lists of approvers re3uired to approve an EC before it
can be released
Step ): "efine Material "ispositions (Optional)
?ou can define your own customized material dispositions, and then assign them to
revised items when defining ECs
Step *: "efine Material "ispositions (Optional)
?ou can define your own customized material dispositions, and then assign them to
revised items when defining ECs
Step +: "efine Priorities (Optional)
?ou can define scheduling priorities for engineering changes to describe the urgency of
your EC
@
Step 1,: Start Auto-mplement Manager (Optional)
&f you automatically implement ECs, you must specify the fre3uency that you want the
%uto&mplement manager to run
A
Clic, on revised items to enter revised items, #$ and routing information.
http:..oracleappscommunit/com.oracle.&log.1+$1.engineering0change0order.
B

C
Clic1 ECO 2evision/
Clic, revised items.
D
1:
11
Manual implementation
Automatic -mplementation
+his program implements all scheduled ECs. &tem status should be 7scheduled8 and
specify an effective date.
12