Candidate for change | Change request form

Candidate for Change | Change Request form

1 Version control
Version Date Status Author Comments
0.1 14.06.2016 Draft Daniela Simon Initial Version

Template Version 4, modified at 15th of November 2013

Note: Section 1 to 7 to be filled by requestor.

All other sections are to be filled by consignee.
LCAG will not fill section 11 – “Official Offer” will be final offer by vendor.
Till section 8, this is a “Candidate for change Description”.
After “Evaluation & Response”, section 9, this form becomes a “Change Request Description”.

Content
1 Version control ................................................................................................................................. 1
2 General Information ......................................................................................................................... 2
3 Verification Criteria .......................................................................................................................... 2
4 Candidate for Change Description .................................................................................................. 5
5 Current Situation .............................................................................................................................. 6
6 Embedded Documents .................................................................................................................... 6
7 Impacts and reasons for change ..................................................................................................... 6
8 Evaluation & Response ................................................................................................................... 6
9 Change Request Description ........................................................................................................... 7
10 Official Offer ..................................................................................................................................... 8
11 Authorized signatures ...................................................................................................................... 9

1
Candidate for change | Change request form

2 General Information
Title: IntegrateStandardBasic_eTracking.doc
EMMA ID: eTCR-616918
Reference to: eTracking
iCAP Project / Stream(s): Handling / Quality Management Service
Requestor: LCAG
(LCAG, IBS, .) Daniela Simon F/IM-AH
First-/Last Name: Alex Mathai Varghese
Vendor: IBS
LCAG:
Date issued: 14.06.2016
Related to other change no.
Impact On Costs in T€: To be filled when the final agreement and sign-off is done
Impact On Project Plan: To be filled when the final agreement and sign-off is done
(high, medium, low, no)

3 Verification Criteria
Please specify and comment the demand for the CfC/CR in respect to the following
categories. The comment is essential to gain approval.

3. 1. CfC/CR introduces no new functionality and/or no new technology compared to Pre-iCAP-Status

YES For any functional / technical change
requested by the CfC / CR, the existing
legacy functionality is to be identified.
iCAP will not fund the CfC/CR!
NO
The CfC/CR Owner has to clarify with business
side to agree on a funding outside iCAP. Any
funding by iCAP must be decided in an appropriate
Review Board (i.e. Domain RB or iCAP RB).

If decided to be funded by iCAP, the development

has to be done with low priority and must not have
any impact / impose any risk on other CfC/CRs in a
higher priority.
Comment

3. 2. CfC/CR is required for iCAP go live

iCAP will not fund the CfC/CR!
YES Explain the impact on the iCAP solution NO
and/or business, when the CfC/CR is not The CfC/CR Owner has to clarify with business
implemented. side to agree on a funding outside iCAP. Any
funding by iCAP must be decided in an appropriate
Review Board (i.e. Domain RB or iCAP RB).
Evaluate alternative options to reduce
the impacts raised. If decided to be funded by iCAP, the development
has to be done with low priority and must not have
any impact / impose any risk on other CfC/CRs in a
higher priority.
Comment An additional module with additional functionality will be provided within iCap for tracking
shipments (Quality Management Service CMT008 and QMS009). Standard functionality
of iCAP will still be the same.

2
Candidate for change | Change request form

3. 3. CfC/CR cannot be shifted to a later point in time and/or release to reduce running cost
iCAP will not fund the CfC/CR!
YES Estimate the one time and recurring NO
The CfC/CR Owner has to clarify with business
cost for implementing the CfC/CR side to agree on a funding outside iCAP. Any
later in time (in a later release). funding by iCAP must be decided in an appropriate
Review Board (i.e. Domain RB or iCAP RB).

If decided to be funded by iCAP, the development

has to be done with low priority and must not have
any impact / impose any risk on other CfC/CRs in a
higher priority.
Comment CfC must go online with iCargo Release 2016/5 according to eTracking Project Plan

3. 4. CfC/CR has been thoroughly checked and discussed with vendor to identify all functions that are
part of the provider obligations (and thus not to be paid again).
iCAP will not fund the CfC/CR!
YES VM to approve explicitly. NO
The CfC/CR Owner has to clarify with business
side to agree on a funding outside iCAP. Any
funding by iCAP must be decided in an appropriate
Review Board (i.e. Domain RB or iCAP RB).

If decided to be funded by iCAP, the development

has to be done with low priority and must not have
any impact / impose any risk on other CfC/CRs in a
higher priority.
Comment There were several discussions to assure that IBS fully understood this requirement.

3. 5. CfC/CR has been thoroughly checked and discussed with vendor to reduce it to its absolute
minimum (to eliminate all not essential requirements).
iCAP will not fund the CfC/CR!
YES NO
The CfC/CR Owner has to clarify with business
side to agree on a funding outside iCAP. Any
funding by iCAP must be decided in an appropriate
Review Board (i.e. Domain RB or iCAP RB).

If decided to be funded by iCAP, the development

has to be done with low priority and must not have
any impact / impose any risk on other CfC/CRs in a
higher priority.
Comment

3. 6. Alternative options (alternative technical solutions, workarounds, modification of business

process) has been evaluated and documented. These options are either not as beneficial and/or are
too expensive (in relation to the CfC/CR proposed).
iCAP will not fund the CfC/CR!
YES Present the alternative options NO
The CfC/CR Owner has to clarify with business
(including benefits and cost) in a side to agree on a funding outside iCAP. Any
separate decision to decide on the funding by iCAP must be decided in an appropriate
solution prior to CR decision Review Board (i.e. Domain RB or iCAP RB).

If decided to be funded by iCAP, the development

has to be done with low priority and must not have
any impact / impose any risk on other CfC/CRs in a
higher priority.
Comment No alternative scenarios/options provided by IBS so far.

3
Candidate for change | Change request form

3.7. CfC/CR corrects an incomplete and / or faulty specification

YES Identify the gap in process and / or
information that have to be optimized
to avoid the incomplete and/or faulty
specification in future.
iCAP will not fund the CfC/CR!
NO
The CfC/CR Owner has to clarify with business
side to agree on a funding outside iCAP. Any
funding by iCAP must be decided in an appropriate
Review Board (i.e. Domain RB or iCAP RB).

If decided to be funded by iCAP, the development

has to be done with low priority and must not have
any impact / impose any risk on other CfC/CRs in a
higher priority.
Comment Pls see description in EMMA ID 616918 respective section 4 of this document

3.8. CfC/CR fixes an existing defect, discovered by a test case.

iCAP will not fund the CfC/CR!
YES Provide the Defect ID NO The CfC/CR Owner has to clarify with business
side to agree on a funding outside iCAP. Any
funding by iCAP must be decided in an appropriate
Review Board (i.e. Domain RB or iCAP RB).

If decided to be funded by iCAP, the development

has to be done with low priority and must not have
any impact / impose any risk on other CfC/CRs in a
higher priority.
Comment

3. 9. CfC/CR is evaluated by vendor to be incorporated into the Standard Product. Thus, no recurring
costs (AMC) are claimed by vendor.
Involve iCAP Vendor Manager for negotiations.
Vendor has to explain, why the CR requested
YES VM to approve explicitly NO cannot be part of the Standard Product.

iCAP Vendor Manager to address the LCAG

Community Manager, requesting him to evaluate
the functional and / or technical aspect in respect
to community benefit.
Comment

4
Candidate for change | Change request form

4 Candidate for Change Description

“Formal” is anything formally agreed between the parties before. S No. / Ref ID are from
Requirement Matrix serial number and reference IDs to clarify the activity changing further.
PSP-Code is from the Project Plan.

S No./Ref ID/ Description

PSP-Code/ Activity (especially describe product alignment (X, C, R) and
Name/ …. impact on maintenance)

[X] Scope MP 6
[X] Formal iCAP Rel. 2016/5
[X] Time
[] Miscellaneous CfC616918_Integrat
eStandardBasic_eTracking.doc

<Remark: It is possible to summarize changes in one CR >

<or textual description>

5
Candidate for change | Change request form

5 Current Situation
Description of the current situation (as-is).
S No./Ref ID are from Requirement Matrix serial number and reference IDs to clarify the
activity changing further.
PSP-Code is from the Microsoft Project Plan for the master project plan for releases, MPs and
increments.

S No./ Ref ID/ Description

PSP-Code/ Activity Name/
…
For the reason that a new product (“Standard Basic”) will be
released, additional information must be provided and displayed in
the new eTracking Web Application.

6 Embedded Documents
Additional supporting documents to be provided by the requestor, if any.
Could be requirement matrix, change log or project plan etc.

7 Impacts and reasons for change

What are the reasons for the change? Why does the change need to be implemented?
Timeline impact, deliverable impact or contract impact to be described apart from any other
impacts.

Reason and Impact for Change Request

(why it is to be implemented?)
See description in chapter 4.

Assumptions and Dependencies to execute the Change

(what else is required in addition to execute the Changes, especially in respect to non-iCAP
systems?)
See description in chapter 4.

8 Evaluation & Response

<free text> (Here the decision process of the consignee will start which is outside of this
template, once the decision is final and agreed internally, the formal evaluation and response
is transferred to this section).

6
Candidate for change | Change request form

9 Change Request Description

<After the Evaluation and Response process is completed>

“Formal” is anything formally agreed between the parties before. S No. / Ref ID are from
Requirement Matrix serial number and reference IDs to clarify the activity changing further.
PSP-Code is from the Project Plan.

S No./Ref ID/
Description CC/
PSP-Code/
(especially describe product alignment (X, C, R) and CR/
Activity Name/ impact on maintenance) R
….
[] Scope There will be a new category of shipments
[] Formal based on the service code attached to the
[] Time shipments. Whenever a shipment is booked
with service code Z, these shipments are called
the standard basic shipments, then for such
shipments there will be a desired TOA and
desired LAT for such shipments. These desired
TOA and desired LAT will not get changed after
the initial booking. For such shipments with
service code Z, Order steering will pass on the
additional values <DESIREDTOA> and
<DESIREDLAT> through transportation plan.

Once the transportation plan is received in

iCargo from Order Steering through ESB,
iCargo will send a success response to ESB,
then ESB will send an event trigger message to
iCargo. For an AWB with service code Z, the
event trigger message will consist of additional
element values for <DESIREDTOA> and
<DESIREDLAT>.

The following changes are applicable in the CR

AWB details screen (ID_200) for a standard
[] Miscellaneous
basic shipment;
1. Under the AWB details collapsible panel, the
<DESIREDTOA> shall be shown with the text
(Go -TOA).
Example- 10 JUN 2016 / 11:02 (Go-TOA)
2. If there is a new TOA update for a shipment
which is different from <DESIREDTOA>, then
the newly updated TOA shall be shown below
the DESIREDTOA in AWB details screen, with
the word “actual” within the brackets.
Example- 10 JUN 2016 14:30 (Actual)
3. Under the AWB details collapsible panel for a
standard basic shipment, the <DESIREDLAT>
shall be shown corresponding to ‘LAT / attest
Acceptance time’.

The following changes shall be made under the

Booking and Acceptance Information collapsible
panel;
1. The LAT / Latest Acceptance Time tab of the
shipment in the “Latest booking details” tab shall

7
Candidate for change | Change request form

S No./Ref ID/
Description CC/
PSP-Code/
(especially describe product alignment (X, C, R) and CR/
Activity Name/ impact on maintenance) R
….
be displayed based on the <DESIREDLAT>
value from the event trigger message.
2. The LAT / Latest Acceptance Time tab of the
shipment in the “Booking at Goods acceptance”
tab shall be displayed based on the
<DESIREDLAT> value from the event trigger
message.
3. If the shipment is not a standard basic
shipment, then the LAT/latest acceptance time
shall be displayed based on the updated LAT in
iCargo.

The following changes shall be made in the

AWB listing screen (ID_210,211, 212)
1. For standard basic shipments, i.e., if the
service code of a shipment is Z in the booking,
then the LAT column in the AWB listing screen
shall be displayed based on the
<DESIREDLAT> value from the event trigger
message.

The following changes shall be made in FSU

BKD;
1. In the case of standard basic shipment, if the
preference for FSU BKD is saved from
Company notification settings with “Include LAT
& TOA”, then the LAT from the <DESIREDLAT>
field from the event trigger message shall be
sent in the OSI line of the FSU BKD.
i.e., In the OSI line in FSU BKD
LDDMMYYHHMMTDDMMYYHHMM, the
highlighted characters shall be shown based on
the <DESIREDLAT> value from event trigger
message.
CC: Customization for Standard
CR: Customization for LCAG
R: Roadmap

< or textual description>

10 Official Offer
(LCAG will not fill this section, only vendors will fill this section)

One Time effort and cost estimation:

per phase Effort / Costs Comment

Specification PD
Build PD
Test PD
Documentation PD
Total effort (sum) PD
Total one time T€

< or textual description>

8
Candidate for change | Change request form

Annual effort and cost estimation (when implemented)

Annual Maintenance per Effort / Costs Comment (i.e. refer to S No./Ref ID/
Item / ID PSP-Code/ Activity Name/ ….)
PD CC Requirement
PD
PD
Total effort (sum) 0 PD NA
Total Maintenance 0 T€

Summary efforts for this Change Request:

MP MP MP
Implementation effort CC [PD] 0 0 0
Implementation effort CR [PD] 0 0 0
Annual Maintenance CR-items [PD] 0 0 0
Dropped effort [PD] 0 0 0

< or textual description>

Any other maintenance related impact on existing (non-iCAP) systems

System / Application Type of impact Comment

Estimation of impact on Project Plan:

< description whether the change has any impact on Milestones of Project Plan or any other
relevant activities >

11 Authorized signatures

___________________ __________________________________
Date Signature Initiator
(<Initiating Party>)

___________________ __________________________________
9
Candidate for change | Change request form

Date Signature Acceptor

(<Accepting Party>)

10