.

        Naming of Transports

a.       Transports should have the module it represents then addition information concerning
the program, report, tcode.  Characters are limited so abbreviations can be used.

b.      Examples below

                                                               i.      ZFAA

– Change in program xxxx for tcode  xxxx                                 - Asset
accounting change in a specific program

                                                             ii.      ZMMM

– Enhancement to table xxx for tcode xxxx                         - Material
Management change for a table and tcode

                                                            iii.      ZBSC

- OSS Note xxxxx for User: xxxx for ZMIN Inventory             - Basis added
an OSS note for a particular module for a developer or business analyst.

3.       Transports in development will need to be released by the basis/change management group in
either India or the U.S.  Developers should not have the ability to release their own transports in
any system.

a.       Will there be a change management person/group in India?

b.      Procedures here are:

                                                               i.      Transports are assigned to developers by change management.

                                                             ii.      Once

the developer is ready for a transport to be moved to the QA system,
they will submit a change request.

                                                            iii.      The

change management team will then release the transport into the QA
system queue.

                                                           iv.      A
job, which runs every 15 minutes, will import the transport into the QA
system.

                                                             v.      Once

the transport is fully tested, by someone other than the developer, the
user will notify change management the transport has been tested.

                                                           vi.      Change

management will then go into the QA work list and approve the
transport to be released to the production queue.

                                                          vii.      Transports are then moved into Production weekly on Sunday evening at
7:00 PM.

 
 4.       Below is the transport route, currently the transport domain in on SR8, however once PR8 –
Production is created we will move the transport domain to PR8.

a.       Transport route and information.

                                                               i.     

                                                             ii.      Once

transports are released from clients 140, 150 and 190 – they are put
into the QR8/100 queue. 

1.       A background job will run every 15 minutes to move transports into
QR8.

                                                            iii.      At
the end of each day, all the transports that have been released from
clients 150/190 in DR8 will be imported into all clients in DR8, as these are client
independent changes for configuration and security.

                                                           iv.      Once

the transports have been tested completely on QR8/100, they are
approved through the QA work list.

                                                             v.      Transport will then be released into the PR8 and TR8 queues.
 1.       PR8 transports will be imported once a week on Sunday evening at 7:00
PM India time.

2.       TR8 transports will be imported on Friday evening at 5:00 PM India

time.

a.       If more than one training client is needed for TR8, we will have
one master training client with master data and set training
data.  That client will be considered the “gold” client and all
transports will be placed in that client.  During the weekend
hours, we will schedule client copies from the “gold” client to
specific training clients.

                                                           vi.      If
a transport is needed to be moved into SR8 – Sandbox, we will move each
transport manually upon request.

From: Manoj Pillai [mailto:Manoj.Pillai@mphasis.com]

Sent: Monday, September 27, 2010 1:14 PM
To: Hitesh Chaurasia
Cc: Kinnari Bajwala
Subject: Details of nomenclature and standarda to be followed

Dear Hitesh,

Kindly get below details clarified from the concern for our operations.

1.        Development class significance.

Details- List is provided. As per the list all our existing modules are covered. We would
like to have more clarification regarding the same so as to educate all concern for
their operational  use.

For e.g. as per the list we have development class as customer development class and
production planning development class now in such case if we have customer specific
development in production planning module then which development class we need
to assign?
 We have following modules implemented in GTFL- Finance and controlling, Materials
management, Sales & distribution, Production planning (Discrete & PP-PI) and quality
management. We would like to have details pertaining to development class to be
used for custom program and enhancement used in above modules.

2.        Conventions and processes followed to create/release transport requests

Details-Do we need to follow any naming conventions for transport requestas per
existing Tyson standards? If so the details /documentation pertaining to the same so
as to educate all the concerns with the same so as to maintain uniform standards.

3.        Authorization for request release to QAS (at a later stage – only to a basis consultant)

Details- Do the consultants have the authorization to release the request created by
them or will it be handled by the Basis team i.e. either US or India? If so what is the
methodology to follow the same so as to maintain the norms as per Tyson
requirement.

4.        Transport route – we had a three system (DEVQASPRD) route for the first two
implementations

Details –Documentation of standards as per Tyson which needs to be followed in case

of transport of request if the same is done from India.

5.        User roles and profiles

Details- Documentation providing details of creation of user roles and profile as per
Tyson standards if the same is maintained in India.

6.        Details of security client 190 i.e pupose.

Confirmation about the below details

 
Sr.No System Package Client ID Purpose Authorization Customizing
To Consultant changes

1 IDES EHP4 200 To configure  SAP_ALL other Allowed

and do the than BASIS
testing by and security
consultants at
preliminary
 stage

2 DEV (DR8) EHP4 140 Client Available Allowed

independent
configuration
work bench
and
customizing

      150 Client Available Allowed

dependent
configuration
work bench
and
customizing

      190 No details NA NA
assume not
applicable i.e.
security

      200 For unit Available Not allowed

testing

3 Quality EHP4 100 For Not available Not allowed

(QR8) integration
testing and
SIT

4 Production EHP4 100 For business Not available Not allowed

(PR8) operation

TMS configured as per details provided –

DR8 QR8VR8PR8TR8

TR8 – If we continue to keep training system

AS per above system specific TMS configuration and details provided in mail dated Sep 23 2010 we
assume the TMS / Changes to be  applicable to various client  as below

DR8 (Client 140,150 &190) QR8 (Client 100)  PR8 (Client 100)

For unit testing in client 200 DR8 consultants will manually transport the changes  using transaction
SCC1.