FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
Document Title: PinICL Incident Management Process
Document Type: Process
Abstract: The scope of this process is to cover the processing of
incidents on the Pathway products. These may have been
raised by the customer or within Pathway or its partners. It
is mandated (a) once a product has been handed over from
one team to another (b) when a team finds an error in its
own products which have been handed over to
Configuration Management. It does not cover incidents
raised as operational hardware problems.
Status: Definitive
Distribution: Library
Pathway Online Standards
Author: John Newitt
Comments to: Author
COMMERCIAL IN CONFIDENCE Page 1 of 30
© 1998 ICL Pathway Ltd
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
0 Document control
0.1 Document history
The following were issued under reference PM/PRD/0003
10/10/96 (0.4) First draft for general circulation
08/11/96 (0.5) Minor classifications
17/10/96 (1.1) Reworks to conform with online HELP.
The following were issued under reference PA/PRO/0014
14/01/97 (0.1) Reformatting and new reference
11/07/97 (2.0) Issued Online HELP plus amendments
21/01/98 (2.1) Incorporates internal review of process
30/01/98 (3.0) Issued updated Word version
0.2 Approval authorities
Name Position Signature Date
S Lee Configuration Manager
0.3 Associated documents
Reference Vers Date Title Source
GENESIS User Guide
0.4 Abbreviations
CM Configuration Management
PCMS Process Configuration Management System (the CM tool used in Pathway)
PinICL Pathway Incident Management System (tool used in Pathway)
PIT Product Integration Testing
SPTS Service Provision Technical Support (a team in T&I)
SSC System Support Centre
T&I Test and Integration
COMMERCIAL IN CONFIDENCE Page 2 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
0.5 Changes in this version
This is a major revamp to fit into the style of Pathway on-line processes format following
internal review. However, parts of the processes for external incidents remain “to be
added”.
0.6 Table of content
1. PinICL Overview 4
2. Process Flow - Raise Internal PinICL Call 5
3. Logging Internal Calls Guidelines 7
3.1 Team Leader (or nominee) validates the call 8
3.2 Example of Description Content 9
3.3 More on References 9
3.4 More on Evidence 10
3.5 More on Products 10
3.6 More on Priorities 10
4. Process Flow - Monitor Call Status by Call Logger 11
5. Work Instructions for Monitor Call Status by Call Logger 13
6. Process Flow - Respond to Call 14
7. Response Guidelines 16
7.1 External Teams 18
8. Process Flow - Analyse Call; ReROUTE if Necessary 19
9. Process Flow - Process Work Package 21
10. Work Package Guidelines 23
11. Process Flow - Test and Close Internal Call 24
12. Work Instructions for Test and Close Internal Calls 26
13. Work Instructions for General Facilities 27
14. Description of Chgd flag 29
15. Response Categories 30
COMMERCIAL IN CONFIDENCE Page 3 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
1. PinICL Overview
The scope of this process is to cover the processing of incidents on the Pathway products. These
may have been raised by the customer or within Pathway or its partners. It is mandated :
e Once a product has been handed over from one team to another
¢ When a team finds an error in its own products which have been handed over to Configuration
Management.
It does not cover incidents raised as operational hardware problems.
Live customer incidents are raised on the PowerHelp system with a link to PinICL.
{bmc PM00.SHG}
PinICL
COMMERCIAL IN CONFIDENCE Page 4 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
2. Process Flow - Raise Internal PinICL Call
Invalid call—
ime PinlCL incident
pm01.ins
{bmc PM01.SHG}
COMMERCIAL IN CONFIDENCE Page 5 of 30
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
Process Owner
Process Objective(s)
Process Rationale
Entry/Input(s)
Resources
Sub Processes
Guidelines
Exit/Output(s)
PinICL Problem Manager
The scope of this process is to cover the logging of internal
incidents (calls) on the Pathway products. These may have been
raised within Pathway or by its partners.
The process details are built round the facilities of PinICL and the
flowchart uses PinICL terminology. In particular, PinICL.
commands are shown in BOLD.
Calls are logged by the originator on PinICL.
The originator routes them to the Team Leader.
The Team Leader reviews the call, signifies approval (or
rejection) and routes the call to the relevant team (defined by the
Progucts (see section 3.5) associated with the call).
A suspected error or technical query from one of Pathway’'s
suppliers or a Pathway unit.
Originating team (may be partner, T&l or development team)
TL - Team Leader
TM - Team Member
None
Logging Internal Calis Guidelines (see section 3)
Call logged on PinICL
COMMERCIAL IN CONFIDENCE Page 6 of 30
FUJ00098253
FUJ00098253
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
3. Logging Internal Calls Guidelines
It is important to remember that the person you are sending the PinICL call to is not a mind-reader
and requires as much information as possible to start solving the problem. The call may be routed
through intermediate teams before reaching the relevant development team. You must not
assume the same level of intimacy with the products - the call must be understood without any
prior knowledge of the testing being conducted. It is also essential that any Year 2000
Compliance or Usability issues are identified.
All newly raised calls must be reviewed by a Team Leader to confirm all necessary information is
correctly logged and that the call is valid (see section on routing). The Team Leader will either
confirm the call and route it, return it to the logger for further action, or close the call if not valid.
The Team Leader will also assess the urgency of the required fix and decide whether the call
requires Fast Tracking, or can follow the standard call life cycle flow.
For each new call:
1. From PinlCL, select Call/New from the menu.
2. Leave Contact unaltered unless you are raising the call on behalf of someone else.
3. Select Target Release from the pull down menu - likely to be ‘Release 2.0’
4. Select Call Type to be:
P - Product error (error in product under test or in test data)
T - Technical query (don't know if error/usability etc.)
(Note L (Live) should only be used by SSC when the call is raised on operational software
on behalf of a user).
5. Select a Priority (see section 3.6)
6. Summary should be a concise one line, indicating the general nature of the fault (e.g.
PMSC204 errors with 1234 under Maestro). Include important keywords that could be
used in later searches (e.g. HelpDesk, CMSC101, BES, error codes, Oracle table names)
7. Select
for routing (see section 3.5). At least one product is mandatory.
8. Use the Reference button (see section 3.3) to specify references such as Test
Reference, Baseline reference, Year 2000 compliance issue or Usability (HCI) issue.
9. In Description, provide an explanation of the problem giving details not already entered in
the Product, Platform, and Reference fields. - e.g. Rig configuration, second linked
platform, what test script was being executed, steps involved up to the point of failure,
what other processes were running, details of files loaded, contents of tables, screen
prints, test phase, test case number, test cell ref., test rig number, personal contact
number (see Example section 3.2).
10. Attach Evidence through the Evidence button (see section 3.4). It can take the form of
e NT Event viewer logs saved as text
e Telnet logs of Oracle table extracts or journals
¢ Screens captured into Paintbrush format via ‘Print Screen’ and paste
COMMERCIAL IN CONFIDENCE Page 7 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
« Message Store extracts — as a zip file if large
41. Do not click on Respond to Call Logger; the call will be returned to the Contact and we
can change this if necessary when the logger moves between teams.
12. All calls raised by testers require Team Leader confirmation. Use Route button and
Route to Person in current team to assign the call to your Team Leader (or nominee).
13. Finally, Send the call to write it to the PinICL database.
14. The Team Leader (or nominee} validates the call (see section 3.1), checking details
and priority level.
Ifthe call is valid, click on Respond and select the TL Confirmed response category.
(This changes the call status from Open to Pending.)
e If Fast Track fix is required, obtain full agreement and authorisation from the three
relevant managers from PIT, Testing and Product Development. (Out of hours, contact
the duty manager.) Specify the names of the three managers in the Response text.
e Ifthe call is a usability issue and has a HCI reference, the call needs to be manually
routed to the Design team (using Route to Team below).
e Route using either Automatic routing required (the normal method which uses
routing provided by the Product) or Route to Team (to specify a specific team e.g. for
usability issues).
e Ifthe call details are inadequate, the team leader may either Route the call back to the
originator or, in extreme cases, Close the call.
Note
All narrative must be of a concise and professional nature; avoid using PinICL to hold
question and answer sessions; it is NOT an Email service. Technical queries are best
handled by personal communication, via the telephone or Em necessary.
REMEMBER our customer has access and can view PinlCL details. KEEP IT
PROFESSIONAL
3.1 Team Leader (or nominee) validates the call
The Team Leader (or nominee) validates the call as follows:
e check the details are complete and correct
check the priority is suitable - if not, change the priority
assess the call for Fast Tracking; if required, it must have Priority A
check that usability issue has HCI reference
check the call is valid (e.g. fault in product requiring fixing, enhancement request)
- if not, Route the call to the originator for correction or closure
¢ check the narrative is of a concise and professional nature
- if not, Route the call to the originator for correction
- or, in extreme cases (e.g. where the wording of the call is not professional), Close the call
and advise/educate the originator to raise a new call correctly
eoee
3.2 Example of Description Content
COMMERCIAL IN CONFIDENCE Page 8 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
Test Phase: PAT / HelpDesk for Release 1c
Test Case No: HD 1.8.3
Test Cell Ref.: PAT Seq10 HelpDesk/PO 123456
Test RigNo: ST01
Contact No:
Description:
Script:
1) Entered ‘Identify Benefit Office’ screen from Main menu
2) Called up Benefit Office
3) Entered 'Enquire and Encash Payments' via Main menu
4) Entered valid NINO XY123499
5) System responded with name details but no encashment details
6) Checked Oracle tables - encashed_payments_1 & encashments_1
See evidence supplied.
ncash Payments', Payments for a customer are not visible
3.3 More on References
Reference fields are used for any key information that can be used for searching at a later date.
Using the Reference button, select an appropriate Reference Type and Reference Value. For
example:
Reference Type I Reference Value
Test reference (to indicate test stage) Test reference ST, DIT, E2E, BIT or MO
Another call Call reference PCnnnnnnn
Baseline reference Baseline * Baseline identifier
PCMS Work Package number Work package *_I PWY_WP_nnnn
Year 2000 compliance issue Y2K * Y2K followed by optional string
Usability/HCI (Human Computer Interface) Usability/HCI * HCI followed by optional string
issue
*~ At the time of writing, it is planned to introduce these references types. If they are not available,
use “Other”.
For each Reference Type, an expected format will be shown where applicable for the Reference
Value but any format can be used. Click on Add.
More than one reference can be added. Ensure that the one you want to be shown on the call
summary screen is selected as Top reference. Click on OK.
COMMERCIAL IN CONFIDENCE Page 9 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
3.4 More on Evidence
If there is external evidence (e.g. a PC file) this can be attached to the call.
Click on Evidence.
Upload the evidence file by clicking on PC file on local machine (or other appropriate field) and
Upload to PinICL buttons and then specifying the Filename on PC field (e.g.
c:\msoffice\filename).
Insert a Description.
Click on Add.
More than one evidence file may be added. Finally, click on OK.
3.5 More on Products
At least one product MUST be defined.
Click on Products
Select a Product Group from the pull down menu (You can enter the first letter of the Product
Group to be offered a more selective choice - e.g. enter ‘o' to be offered a choice of ‘OBCS’ and
‘Oracle').
Then select a Product from the pull down menu and, if appropriate, a Version.
Select a Platform from the pull down menu.
Click on Add for each product/platform. Note that the product and platform entries are logically
independent in spite of being set up together. (If you define more than one product, ensure that
the one you want to use for routing is marked as the Subject product.)
Click on OK.
3.6 More on Priorities
Each call type has a set of priorities each with a target response time; this is the number of
working days within which a response is expected.
Currently, the priorities are the same for each call type (except R which has a special purpose):
A Business stopped 1 day
B Progress stopped 3 days
c Progress restricted 5 days
D Non-urgent 10 days
The descriptions (but not the target response times) are displayed in the pull down menu.
COMMERCIAL IN CONFIDENCE Page 10 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
4. Process Flow - Monitor Call Status by Call Logger
PiniCL incident
v v v y
Pending response
call not asdgned to ACTION set Newly assigned to Newly assigned to
team member team
team
' i '
I__Final response
(intemal call)
[— (External call)
Stora ral
Evidence
required
==
PinICL incident
Process
pmo2.ins
Others um
{bmc PM02.SHG}
COMMERCIAL IN CONFIDENCE Page 11 of 30
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
Process Owner
Process Objective(s)
Process Rationale
Entry/Input(s)
Resources
Sub Processes
Work Instructions
Exit/Output(s)
PinlCL Problem Manager
The scope of this process is for Call Loggers to monitor their
PinICL call stacks and to take appropriate actions. It covers
responding to actions placed by other teams, noting pending
responses, adding evidence and dealing with calls that have been
routed back to them.
The process details are built round the facilities of PinICL and the
flowchart uses PinICL terminology. In particular, PinICL
commands are shown in BOLD.
Actions may be placed on any team to either request information
from or to pass information to that team. Teams need to monitor
such actions; when one is placed, they need to respond to it and
to unset the action marker. Only one action can be set at a time.
When a call responder has made progress on resolving an
incident, he/she may provide a pending response. The call logger
should read this response and take any appropriate action or
make suitable plans. One particular value of pending response is
the request for further Evidence (see section 3.4); the Respond
to Call process states that the call should have been routed to the
team.
When a call is transferred with Final status, the appropriate
process for testing or accepting the response and closing the call
needs to be followed.
Monitoring of PinICL stacks should be done regularly (at least
twice each day).
Call logging team (may be partner, T&l or development team) or
any other team accessing PinICL.
None
Monitor Call Status By Call Logger (see section 5)
Updated PinICL call
COMMERCIAL IN CONFIDENCE Page 12 of 30
FUJ00098253
FUJ00098253
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
5. Work Instructions for Monitor Call Status by Call Logger
This section deals with the monitoring of calls for actions placed on you or pending responses
which require additional evidence or are reporting progress. See also Work instructions for Test
and Close Internal Calls.
Monitor your calls twice each day; the Refresh button updates the display.
You can identify calls newly assigned to you by the Ghgd flag (see section 14).
Actions may also be placed on you and these will be signified by an entry in the Actioned
columns on the display screen.
lf a call is actioned on you even though you are not the call logger or in the assigned team, the call
will still appear on your display screen.
1. Monitor your calls twice a day looking for any which have Chgd (see section 14) or have
an Action placed on you. If the call has recently been assigned to your team, reassign to
a team member (via Route) unless you are going to deal with the call straightaway.
2. If an Action has been placed, the details of the action should be in the Progress
Narrative. You need to do whatever is necessary to satisfy the action, adding New
Progress Text if appropriate. Unset the action: Click on Action and click on No
outstanding action button; click on OK.
3. The call responder may request additional evidence by using a special pending response.
You should attach it as Evi: (see section 3.4). If the call is assigned to your team,
Route the call back to the team which requested the evidence.
4. If any other pending response has been provided, note the information and make
appropriate plans if necessary.
5. If a call is transferred with Final status, the appropriate process for testing or accepting
the response and closing the call needs to be followed.
COMMERCIAL IN CONFIDENCE Page 13 of 30
ICL Pathway PinICL Incident Management Process
Ref:
Version:
Date:
FUJ00098253
FUJ00098253
PA/PRO/O14
3.0
30/01/98
6. Process Flow - Respond to Call
Subsequentasks
sreassigned he
role of Team
Member
a] ’
oHHTE
Normal case for
caltypeP
Fastrack case br
caltypeP.
Internal catwit ro
deliverable
Normal ease for
Livecalls
Calineeds be
progressed fo
another bam(e ¢
Develonment)
COMMERCIAL IN CONFIDENCE
Page 14 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
{bmc PM03.SHG}
Process Owner
Process Objective(s)
Process Rationale
Entry/Input(s)
Resources
Sub Processes
Guidelines
Exit/Output(s)
PinICL Problem Manager
The scope of this process is to cover the processing of incidents
by the call responder, typically a member of a development or
support team.
The process details are built round the facilities of PinICL and the
flowchart uses PinICL terminology. In particular, PinICL.
commands are shown in BOLD and the diagram refers to specific
RESPONSES.
The following significant tasks need to be accomplished:
i. Analyse call; reroute to another team if necessary
ii. Route the call to a team member
ili, Request additional evidence
Iv. If a new error is diagnosed, inform call logger, fix error
and handover to appropriate team
v. If the diagnosis is that this is one of
- a known error,
- an enhancement request,
- there is no error in the product,
- a workaround is available
- a duplicate call
then a response is sent to the call logger.
[There is also a category of “administrative closure” which is used
for situations such as the withdrawal of the call by the user.]
If more time is required to diagnose the call, the target date may
be amended.
A call has been logged on PinICL and passed to a call responder
team.
Call responder team member (default resource)
Call responder team leader
Analyse sary (See section 8)
ReROUTE
Response Guidelines (see section 7)
Updated call logged on PinICL
Deliverable (e.g. Code)
COMMERCIAL IN CONFIDENCE Page 15 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
7. Response Guidelines
PinICL calls raised on the Live Environment are screened by SSC before passing to the relevant
response team (e.g. Requirements, Design or Development). All newly opened Internal calls are
reviewed by a Team Leader to confirm that the call is valid, correctly logged and contains all
necessary information. Once the call has been confirmed it will be routed by Product to the
relevant Response Team.
Response Team Leaders must view their PinICL call stacks regularly and all calls must be
responded to within the Pathway target response time as defined by the priority rating given to the
call. The progress of ‘A’ Priority and Fast Track Calls must be monitored hourly by the Team
Leader and progress narrative added within the required guidelines.
The Response Team Leader will also be required to carry out the following tasks.
Analyse calls, check the validity and progress as follows:
e Suspected error in the product requiring code fix - Assign to Team Member
e Believed to be an enhancement which, if required, would have to be progressed as a CP (e.g.
a tester may have identified a major shortcoming of the system) - Add enhancement request
response code and qualifying narrative; the call will auto-route back to the logger for further
progress.
e Known not to be a requirement of the system - Add qualifying narrative and “no fault in
product” response code; call will auto route back to Logger
Incorrect detail or routing - Update call with correct information (e.g. Product Type, References
etc) add qualifying narrative, and re-route to correct team if necessary.
The assigned Team Member will be required to carry out the following tasks.
If the call needs to be processed by an external (to PinICL) third party, see section on External.
Teams (see section 7.1). Otherwise, carry out diagnosis. Use the Respond button; the pu
menu indicates the ies available (see section 15). Progress the call as
follows:
¢ Diagnose Error - Confirm product error against Design requirement. Add “Product error
diagnosed” response code and details of plan for fixing the problem.
° Year 2000 Compliance or Usability (HCI) Issues - It is essential to separate Year 2000
compliance or Usability issues from general acceptance issues at New Release 2. If during
diagnosis it is considered that there is a Year 2000 compliance issue or a usability issue, add a
Reference (see section 3.3) (Reference Value “Y2K” or “HCl” with qualifying narrative). In
either case, use response code “Progress update” and route to Design.
e Fix Error - Add narrative with detailed information of fix, including which modules (or
documents, etc.) have been amended and data on recreation of the problem fixed. Where
appropriate, create a knowledge entry.
The subsequent processing depends on the type of call and the team dealing with it. Except
where otherwise stated, the response code is “Product error fixed”.
[Response Team _I Type of call [Action I]
COMMERCIAL IN CONFIDENCE Page 16 of 30
ICL Pathway
PinICL Incident Management Process
FUJ00098253
FUJ00098253
Ref: PA/PRO/014
Version: 3.0
Date: 30/01/98
Development, Design
ete.
Live. Fix is specifically for the live
environment.
Add response code; route to CM
and voice prompt.
Development
Call is a Fast Track .
Add work package number as
Top Reference
(PWY_WP_nnnn). Add response
code; route to PIT; voice prompt
PIT Manager and own Team
Leader
Development
Call is not a Fast Track, has a
deliverable (the normal case)
Add work package number as.
Top Reference
(PWY_WP_nnnn). Add response
code and route call to relevant
Development Integration Release
Team*
Development
Call has no deliverable (e.g. call
type T)
Add response code and route
call to Originator
Requirements,
Call fixed
Add response code “Fix
released”; this auto routes call to
originator
Design etc.
Requirements,
Design etc.
Call needs to be progressed to
another team (e.g. Development)
Add response code and route
call to relevant Team
* Whilst a call is in Development Integration Release Team, the Design team may monitor calls
to ensure that there are no “knock on” effects to the overall Product design
More evidence required - Add “Evidence required” response code and detailed narrative of
requirement; route to call logger.
Enhancement required - Confirm with Team Leader, then add “Enhancement request”
response code and detailed narrative of requirement; the system auto-routes the call back to
the logger. [The logger (via the team leader) decides whether to submit the call to
Requirements or Design.]
No error diagnosed - Add “No fault in product” response code and qualifying narrative (e.g. this
is not a requirement of the system). Call will auto route to the logger.
Known error - If a knowledge entry exists, create a link. Use References to include any linked
call numbers, CP number, KPR entry etc. Add “Published Known Error” response code and
detailed narrative. Call will auto route to the logger.
Workaround available - Add “Avoidance action supplied” response code and narrative detailing
a proposed plan for a permanent fix. Call will auto route to the logger. The logger can accept
the workaround and submit the call to Requirements for entry on the KPR and closure, or
resubmit for a permanent fix._
Duplicate call - This applies if the call is a duplicate of another call but the error has not been
published (e.g. via a knowledge entry, CP or a KPR entry). Use References to include linked
call numbers. Add “Duplicate call” response code and detailed narrative. Call will auto route to
the logger.
Progress update - All calls are given a Pathway priority rating A, B, C, or D and the Call
Responder must progress calls accordingly. Calls must also have regular progress updates at
least every:
COMMERCIAL IN CONFIDENCE Page 17 of 30
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
A= Half Day B= Day C=2 Days D=5 Days
Response code “Progress update” should be used when adding progress updates.
* Target Update - If the call will not be resolved within the Priority time frames then the Call
Responder must update the target date and time with a realistic expected delivery time, and
progress the call with detailed reason narrative. Call target response times are:
A priority 1 day B priority 3 days C priority 5 daysD priority 10 days
The above response guidelines are based on the typical first response to a newly raised call
where the first response team would normally be a Development team.
If the call has been routed on for further responses, e.g. to Design or Requirement, then not all of
the Team Leader or Team Member tasks may be relevant and can be omitted accordingly.
Note
All narrative must be of a concise and professional nature; avoid using PinICL to hold
question and answer sessions NOT an Email service. Technical queries are best
handled by personal communication, via the telephone or Email if necessary.
REMEMBER our customer has access and can view PinlCL call details. KEEP IT
PROFESSIONAL
7.1 External Teams
Information may be required from an external team which does not use PinICL. Click on Action
and Action on External Party. It is your responsibility to send details on suitable media (fax,
email etc.), to chase them if necessary for a response, to input their response into PinICL; and
Unset the Action. Depending on the response, the Team Leader or Team Member needs to
decide on the next appropriate step.
COMMERCIAL IN CONFIDENCE Page 18 of 30
FUJ00098253
FUJ00098253
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
8. Process Flow - Analyse Call; REROUTE if Necessary
FiniCLineident
NE
one
1
u’
extrnalteam
y
COMMERCIAL IN CONFIDENCE Page 19 of 30
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
{bmc PM05.SHG}
Process Owner
Process Objective(s)
Process Rationale
Entry/Input(s)
Resources
Sub Processes
Guidelines
Exit/Output(s)
PinlCL Problem Manager
The scope of this process is the detailed procedures involved in
validating the call and rerouting it, possibly to external parties.
This is a sub process of Respond to Call Process.
When a call is received by a Call Responder Team, the team
leader must analyse it, and route to a team member, another
team or back to the originator. If the call needs a response from
an external (to PinICL) party, information must be recorded on
PinICL whilst ownership remains within the team.
A call has been received by the Call Responder Team for
analysis (and rerouting if necessary).
Call Responder Team = TL Team Leader
™ Team Member
External team
Note, the TL may allocate work to him/herself as a TM.
None
These are part of &: elines(see section 7)
Updated PinICL call.
COMMERCIAL IN CONFIDENCE Page 20 of 30
FUJ00098253
FUJ00098253
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
9. Process Flow - Process Work Package
FastTrack path
ato aca
process by PIT ‘yomobats
ang SPTS into baseline
PiniCL inecent
PiniGL indent
pet Ob.ins
{bmc PM10.SHG}
Process Owner : PinICL Problem Manager
Process Objective(s) : The scope of this process is the building of PinICL calls that have
fixes into Work Packages and the progress of the Work Package
into and out of Integration Testing. It deals with both Fast Track
and normal calls. It does not deal with the Integration processes
themselves.
COMMERCIAL IN CONFIDENCE Page 21 of 30
ICL Pathway
Version: 3.0
Date: 30/01/98
Process Rationale
Entry/Input(s)
Resources
Sub Processes
Guidelines
Exit/Output(s)
This is a sub process of Respond to Call Process. Deliverables
(e.g. code) are built into Work Packages. Progress of deliverables
is recorded on PCMS rather than PinICL and so is outside the
scope of this process.
Each Fast Track call fix forms a separate Work Package. The
PinICL call follows the Work Package into PIT.
Ordinary call fixes are merged into meaningful units for baselining
and testing (i.e. a Work Package). Whilst the Work Package is
progressed through the various stages of Integration testing, the
associated PinICL calls are retained by Development under a
special team “Development Integration Release Team”. Once the
release has been approved, this team moves the calls back to the
Originator (typically a Testing team).
A call has been fixed by a member of a Development Team and
is ready for Integration testing.
Dev Team relevant Development Team
Dev Int Rel Team Development Integration Release Team
SPTS
PIT
None
Work Package Guidelines (see section 10)
Updated PinICL call.
COMMERCIAL IN CONFIDENCE Page 22 of 30
FUJ00098253
FUJ00098253
PinICL Incident Management Process Ref: PA/PRO/O14
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
10. Work Package Guidelines
When a Development Team has produced a fix for a call (other than a Live call) which requires to
be baselined, it is built into a Work Package and follows one of two routes:
Development Team fixes error (not a Fast-track call)
1. Development Team routes call to Development Integration Release Team
2. Development Integration Release Team:
collate PinICL calls into Work Packages
confirm / add WP number in top reference (PWY_WP_nnnn)
confirm /add response category “Product error fixed”
hold PinICL calls
deliver Work Packages into Configuration Management (PCMS)
. Work Packages are processed through PIT and SPTS who record progress on PCMS
. PIT/SPTS create the Baseline and authorise the release
. Development Integration Release Team update PinICL calls with Baseline details
. Development Integration Release Team route calls direct to the Originator (normally Testing)
by responding with response category “Fix released”
. The Originator (Testing) conducts a test, closes the call (or routes it back to Development
Team if the original problem has not been resolved).
8. In parallel with other work, Design can monitor the fixes as required and discuss with the
appropriate teams any potential issues.
OnRweeeee
~
Development Team fixes error in Fast-track call
A Fast-track call requires joint authorisation from Product, PIT, and Testing Managers.
Each call forms a separate Work Package.
1. Development Team:
adds WP number in top reference (PWY_WP_nnnn)
deliver Work Package into Configuration Management (PCMS)
routes the PinICL call to PIT
voice prompts the PIT Manager and their own Team Leader
Work Packages are processed through PIT and SPTS who record progress on PCMS
. PIT/ SPTS internal process promotes fix into Baseline
. PIT update PinICL call with Baseline details
. PIT routes PinICL call direct to the Originator (normally Testing) by responding with response
category “Fix released”
. The Originator (Testing) conducts a test, closes the call (or routes it back to Development
Team if the original problem has not been resolved).
7. In parallel with other work, Design can monitor the fixes as required and discuss with the
appropriate teams any potential issues.
HAWNe eee
o
COMMERCIAL IN CONFIDENCE Page 23 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
11. Process Flow - Test and Close Internal Call
PinlCL incident Deliverable
Not OK
PinlCL incident PinlCL incident
{omc PM04.SHG}
Process Owner : PinICL Problem Manager
Process Objective(s) : The scope of this process is to cover the acceptance and/or
testing and closure of internally raised incidents.
Process Rationale : The process details are built round the facilities of PinICL and the
flowchart uses PinICL terminology. In particular, PinICL.
commands are shown in BOLD and the diagram refers to specific
RESPONSES.
In Respond to Call, a response has been made on PinICL; this
response has to be accepted (by testing or otherwise) and the call
closed on PinICL. If the response is rejected, then the process
returns to Respond to Call.
Entry/Input(s) : Call with response on PinICL.
COMMERCIAL IN CONFIDENCE Page 24 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
Deliverables (where a fix is provided)
Resources Original logging team
Sub Processes
Work instructions
Exit/Output(s)
None
Test and Close Internal Call (see section 12)
Updated PinICL call which may be closed.
COMMERCIAL IN CONFIDENCE Page 25 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
12. Work Instructions for Test and Close Internal Calls
1. If the call has resulted in a software fix, you need to test the new code.
2. If the call has resulted in a final response without a software fix, you need to approve the
response
3. If you are satisfied, enter a summary in the New Progress Text
For example, “This fix has been tested successfully.” together with further details if useful.
The call should reach you in Final status. Click on Close Call and then Send.
4. If for some reason the call status is not Final, you need to investigate why the call has not
followed the normal life cycle. If possible, get the team which sent the call to you to
change the call to Final. As a last resort, click on Close Call and then Send. This will
respond with a Call Response screen; select Response Category 8 - Administrative
Response and add suitable Response Text
Click on OK.
5. If you are not satisfied with the response, and want to return the call, click Respond,
update the Response Category to 2 - Progress update and Route the call to the
relevant team for further attention. (It is good practice to discuss this with the relevant
team to avoid calls bouncing backwards and forwards.)
6. If you are not satisfied with the Response Category, but are happy to close the call, click
Respond, update the Response Category to an appropriate value (see section 15), click
OK and then Send. You then have to open the call again and click on Close Call.
COMMERCIAL IN CONFIDENCE Page 26 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
13. Work Instructions for General Facilities
Set Up Options
The PinICL Administrator normally sets default values for new users. You may need to change
these, especially if you move teams.
Call logging defaults are defined in the menu Options/Call Details Defaults. The
recommended values are:
User as Contact
Show audit details with progress text
Default Call Type as “P - Product error”
If you are a member of more than one team, check that your Team used for Call Logging is set
appropriately.
Most users will use one of call types P and T. Do not use the others unless you are given specific
instructions. The list of possible call types is
Call type Description
A Administrative use
L Live use error
M Model Office raised by SIS
N Model Office raised by PDA
P Product error
R Release Notice Forum
T Technical query
Call summary defaults
All users have a stack of open calls that can be displayed. The defaults are defined in the menu
Options/Call Summary Defaults. The recommended values are:
Set Display on System Entry in top left box and select both Where User is Assignee and
Where User is Call Logger. Team leaders should use the User’s Team option; other team
members may choose the User only option unless they need to monitor calls for other team
members. If you use User’s Team option, select the teams required.
[NOTE - at the time of writing, there is a known error such that calls may be omitted from this
display summary. See Knowledge Entry PKO000209 for latest status
It occurs if you are a member of more than one team and you have your Options/Call Summary
Defaults set as:
Where “User is Assignee" is selected AND teams = All user's teams AND where “User is Cail
Logger" selected (regardiess of whether you select a single team or Ail user's teams)
It appears to provide correct results if you select a single team for “Where User is Assignee" or do
not select the "Where User is Assignee" option.
It is RECOMMENDED that you unset the "Where User is Call Logger" option and you obtain this
information via a stored Search.]
COMMERCIAL IN CONFIDENCE Page 27 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
Define Search
To do this, select Generate special query from Call/Search and click on OK. On Call Search
screen, specify a Search Title
Use pull down menus to construct selection tests. Click on Add Phrase. Additional tests can be
added. A maximum of 5 tests are allowed (although with “long” clauses, the maximum may be 4).
If a mixture of ANDs and ORs are used, you should insert brackets in the generated syntax.
If you want to change the default sequence, unset the button in the Contents and sequence to
be as on default summary display; select field from display fields pull down menu in the
bottom right corner and click on Add. If you want to delete a field from the sort sequence highlight
it and click on Delete.
Click on OK. When the search is displayed, you may change the layout by:
You can extend or contract the width of a column by pointing and holding down the mouse on a
column divider in the column heading area and moving it to the left or right.
You can move a column to another position by pointing and holding down the mouse on a column
heading (which highlights the column heading) and then dragging and dropping it into the required
position.
You can sort the summary list on a particular column by pointing to a column header and clicking
on the right mouse button.
To complete the setting up of this as a standard search, click on Save Layout at the bottom of the
call summary screen.
Create a subset of a summary display
If your list of calls is long you may wish to limit your display to a subset of the full list. You should:
With arrow, move to first call and press Return
With arrow, move to last call in group and press Shift+Return
Additional calls can be selected by use of Control+Return (but it is not possible to select additional
groups other than by selecting each individual call). Another technique is to select a "super group"
as above and then unset individual calls by Control+Return.
You can use a subset of calls for printing; alternatively, press "Subset" to restrict the calls in your
summary list.
You can also use the cursor to select calls by moving the cursor to the left-hand side of the list;
the cursor changes to a tick. However, the keyboard method above is often easier than use of the
mouse.
COMMERCIAL IN CONFIDENCE Page 28 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
14. Description of Chgd flag
The following is extracted from the user manual:
The default summary displays includes a Chgd column. This is used to flag changes to specific
users, although the flags will be shown for all users so that you can see if the person for whom the
flag is intended has in fact viewed the call.
The following values, in the first column of Chgd, flag information for the assignee or assigned
team:
N This is set when a call is routed, manually or automatically, and newly arrives on a team
stack. It applies to all members of the team who have opted to display all calls assigned to their
team. It will be displayed until the call is viewed by team member or is in some other way updated
by one of the team members. It is also set for an individual user when a call is newly assigned to
that user; it will be cleared once he has viewed the call details.
Cc This is set when a user other than the assignee updates a call. It is cleared when the
assignee has viewed the call details.
The following value, in the second column of Chgd, flags information for the call logger:
P This is set when a plan response has been sent. It is cleared when the call logger has
viewed the call.
Note these Chgd flags will only show when the summary screen is refreshed and if you have the
call displayed on your current list (depending on whether or not you have a subset selected).
COMMERCIAL IN CONFIDENCE Page 29 of 30
FUJ00098253
FUJ00098253
ICL Pathway PinICL Incident Management Process Ref: PA/PRO/O14
Version: 3.0
Date: 30/01/98
15. Response Categories
Response Categories have a Status of Pending or Final. When you supply a Pending response,
the call remains with you unless you Route the call elsewhere. When you supply a Final
response, the call automatically transfers to the originator (call logger).
The response categories vary according to the call type.
The current values available for call types P (Product error), L (Live) and M/N (Model Office) are:
Pending Final
5 - Published known error
6 - Enhancement request
7 - No fault in product
8 - Administrative response
9 - Avoidance action supplied
13 - Fix released
16 - Duplicate call
4 - Evidence required
2 - Progress update
3 - Product error diagnosed
4 - Product error fixed
17 - TL Confirmed (call types N/P)
[The following Final categories have
100-299 for call types L, M, N should
The current values available for call t
limited use:
be used only by the SSC.]
pes T (Technical query) are:
Pending Final
2- Progress update
17 - TL Confirmed
6 - Enhancement request
9 - Avoidance action supplied
12 - Answered
16 - Duplicate call
The current values available for call types A (Administrative use) are:
Pending Final
2- Progress update
17 - TL Confirmed
6 - Enhancement request
8 - Administrative response
COMMERCIAL IN CONFIDENCE Page 30 of 30