KnowledgeTransfer ENG

Knowledge Transfer
Process
AMS Model 2.0
All Rights Reserved Valores Corporativos Softtek S.A. de C.V. 2011. Internal.
Agenda
Fundamentals
AMS Life Cycle
Sibling Processes
Knowledge Transfer
Definitions
Goals and Objectives
Process
Steps
Risks
Knowlege Base & Other References
AMS Life Cycle
Knowledge Transfer
Process that allow to get Application Information

from incumbent vendor to our organization.
It belongs to Service Desing Phase
Knowledge Transfer Goal & Objectives

Goals
To ensure all the information, applications, products are correctly delivered for
AMS starting.
Objectives
Define guidelines for transitioning applications in the AMS engagement from

the incumbent vendor to Softtek. The guidelines are to be used while
preparing the detailed knowledge transition plan for each of the applications.
The Transition phase may include all or some of the following:
Goals &
Objectives
CSF
KPI
Due Diligence
Transition Planning & Initiation
Process Understanding (Knowledge Acquisition)
Parallel Support (Primary Support, Secondary Support)
On Boarding Criteria
Primary Support Transition to steady state. Note: For a particular application
or group of applications some of the phases may be merged into a single
phase based on the complexity and duration of the Knowledge Transition
KT Risks
Risks for Knowledge transfer
The risks identified as critical on any regular knowledge transfer process, are
documented below. These are risks that AMS team has to evaluate in order to avoid
any distraction on the operational aspect of the delivery, and have a mitigation plan
for every single risk that is identified.
Not enough time dedicated to knowledge transition, especially from SMEs.
A mitigation plan for every key resource that is critical for service delivery is not
defined.
Inadequate transition plans and effort oriented to learn everything
Lack of prioritization by the Customer.
A retention knowledge plan for core AMS team is overlooked.
Incorrect time estimates are the downfall of many projects. One factor for incorrect
time estimates does not comprehend the importance of learning curves
Responsibilities for knowledge Transfer

Customer Activities during the
knowledge transfer
Communicate the Plan for the
current organization.
Priorities Validation.
Approve the Transition Planning
Validate the missing critical
information for knowledge transfer.
Approve the Mitigation Plan.
Support and Facilitate the ongoing
issues for the transition.
Sign-off the completion of the
Knowledge Transfer.
Owner of the Application Activities

during the knowledge transfer
Commitment to the knowledge
transfer Plan and availability
facilitate the knowledge of the KT
activities,
Follow the Transition Planning
(milestones),
Indicate the missing critical
information for knowledge transfer
Provide the High Level process
Support and Facilitate the
interaction with different
organization
Checklist complete for Knowledge
Transfer
Strategy for Knowledge Transfer

Prep. Meeting and Initial Kick-Off Meeting
Understand the Customer Priorities
2
3
Kickoff Meeting
4
Due diligence
Prioritizes the KT Plan base on criticality, and out coming vendor
5
Establish Risk Management
6
Create and commit the KT Project Plan

7
Start Knowledge Management on applications

Tracking and Execute the KT Plan
Status Meeting & Knowledge Evaluation

10
Gustavo.Acosta@.ge.com
Sign off transitions
Implementation Roadmap
Understand AS IS and
make a diagnosis and
recommendation
Take full ownership of

knowledge and operation
Deliver live according to

SLAs and with productivity
gains
Operation
Transition
Assessment
Service Level
Agreement
Monitoring
Assessment
RFP
Change
Request
Knowledge
Transfer
Parallel
Operation
Kick
Off
GAP
Operation
Process &
Methodology
Tailoring
Process
Improvement
Tollgate 0
Tollgate 1
Tollgate 2
Sign off
Transition
Out
Transition Road Map

Planing
Due Diligence
Historical Cases
Identify key resources
Finalize scope
Contact stakeholders
Project strategy
definition
Communication
Customer CTQs
Knowledge Mgmnt
Configuration Mgmnt
Tools
Metrics Definition
Risk Mgmnt
Setup near shore

infrastructure
Kick off
Knowledge
Acquisition
Functional K
Business processes
Business rules
Applications
Technical K
Infrastructure
Environments
Security
Induction Process
Softtek Engineering Process

AMS Process
Customer Induction
Process
Evaluate actual K acquired

(GAP)
Create new risks and
issues requirements
Update detailed KT plan
Parallel
Operation
Setup
Operation
readiness
Evaluate results from the

gap analysis and define
action items to follow
Pilot Operation 1
Prioritize potential process
Primary support
improvement projects
Incumbent Vendor
Take final ownership of on Secondary support
going tasks
Softtek
Start execution of day to day
Pilot Operation 2
Primary support Softtek tasks
Secondary support
Start Service Management
incumbent vendor
Knowledge Transfer
Process fine tuning
Completed (Sign-Off)
Initial metrics
Finalize transition out of
Cross training
incumbent vendor process
Evaluate actual K
Parallel Support - Primary
acquired (gap)
On Boarding Criteria(Go or
not Go)
Formalize Closing KT
Environments
Accesses
Overall Process - Signoff & Move to

Steady State
KT Begins
Stage 2
Secondary
Support
Stage 1
KT
Stage 3
Primary
Support
Incumbent
Agrees
Yes
Service
Manager
Agrees
Yes
Quality Assurance
Docs
Collected
AMS Lead Sends a

Note to Customer
confirming ready for
review
Docs
Read &
Reviewed
Signoff w/Gaps
KT Exit Criteria
Sec/Pri Support
Scorecards
Ready
for Stg 4
Lead Makes
Adjustments &
Repeats Signoff
Steps
Yes
Exceptions
Yes
Remediation
Reqd?
Issue List
Stage 4
Steady
State
Track
Sheets
Business Process Mapping

Signoff OK
Track Service
Manager and
Evaluate
Update Service
Manager
Exit
Criteria
Updated
Signoff
Sheets
KT Manager
Initiate audit
process
Signoff NOT ok
Docs
Uploaded
Customer
Lead
Agrees
Operational Process
Operation Plan
KT Planning
Prioritization 80/20 Rule
Focus on critical, high volume apps., where most time is spent supporting
Focus on high use areas or error prone components of a system
Quality Documentation
Focus should be on quality, for the prioritized documents. Not volume.
Leverage high quality examples from GAMS for deliverables
Leverage Clients for Functional Documentation

Business Process flows
Business Calendars
User Manual/Operational WIs
Deliverable Focused KT Sessions

Create Deliverable PRIOR to session
Create Deliverable DURING session
Output needs to be generated during KT (align process understanding docs to deliverables)
Catchers can create Deliverables (at least draft versions at a minimum)

Support Document
Architecture/Network Diagrams/Interface Diagrams
Document Validation Tool

Mandatory's
Business Process Mapping L1, L2
Functional Documents (Mandatory)
Technical Guide (Mandatory)
Test Cases (Mandatory)
Application Configuration Guide
(Mandatory)
Deployment Guide (Mandatory)
Application production Support Guide
(Mandatory)
Application Disaster Recovery
(Mandatory)
Optional
Architecture Guide (Application and
Database)
FMEA (Failure Modes and Effects
Analysis) (optional)
User Manual (Optional)
Issues Log (Optional)
Prototype (Optional)
Use Cases (Optional)
Class diagram (Optional)
GAP Analysis
Gap Analysis Conducted First Input to KT Plan. Raise Issues early.
System Description Document (Required to be completed)
KT plan should include Tasks to fill gaps
Prioritize and assign KEY deliverables. Allocate Time in plan.
Expectation Setting Deliverable Focused!!!!!
Raise Issues - Identify Gaps in Documentation at risk to being completed
At a minimum, capture Training Notes/Understanding Documents

Format/Template is not specified
Needs to be understandable, not perfect, can be polished later
Save Understanding Documents to System Repository
Extra capacity for Incumbent resources

During transition to Secondary, Primary and Steady State
Incumbent resource should have time available to create documentation
Links to System Documentation Repository
Business Modeling Business Process

Collaboration
Supplier
Optimization
Manufacturing
WMS
Distribution
Subsystem B
System A
TMS
Demand
Wholesale/
Retail
SFA
Consumer
Business Modeling System Context

example
sales order
Sales Order
System
purchase order
Suppliers
goods returned
goods unavailable
notice
shipping slip
Warehouse
Inventory
System
supplier delivery
checked supplier
invoice
Accounts
Department
Business Modeling System Context

Business Process Relations
eCAM
QAS
QAM
Trigger
eNMS
MDRS
QEM
ENACT
EDSARS
ePQAR
Calendar or
Perpetual Audit
Tag Data
Collection
eCAR
Relations
Generation based in
User Analysis
Source
Profiles
Only association
Automatic process
Data and information sources all apps
IMPACT
Business Modeling Business Process

Diagram Levels
System Context
Business
Process
1
2
A
1.1
Business
Process
Relationships
Business Process
HIGH Level
1.2
Business Process
Second Level
On-Boarding
Kickoff Meeting Agenda

Purpose - The purpose of the kickoff meeting is to have a brief initial discussion to allow the project team to advise the support
team about their application and its support needs and for the support team to educate the project team concerning the support
processes.
Meeting duration : 30 to 60 minutes
Meeting arranger: Customer/ Service Manager
Attendees:
Operations: On-Boarding lead

Service delivery leader
KT Manager
Support Team ( if other teams are required )
Project Team: Functional Lead
IT Lead
The project team should be prepared to present the

following:
Brief overview of the application

Does the application have any special characteristics, such
as export control or strategic technology data or
extended service hours of support.
Describe any software required that is not part of the
standard Customer technology stack
Define environments (DEV, QA, PROD) available to
support team for providing their service.
Estimated implementation ( incoming release to production)
date
Current Issues, Backlog, Enhancements plan
The support team will describe the following:
The Support document and the sourcing process

to procure support agreement
Overview of application SLA agreements and
implications.
Discuss any project team questions concerning
the Support Guide
Any questions regarding documentation.
Review AMS team has provided its escalation
process to the functional owner and the function
owner has provided their required notification
points to the AMS team
Softtek Acceptance Sheet

Knowledge transfer has been completed to the vendors satisfaction and vendor is ready to accept AMS Delivery
responsibility.
Any FAQs, support diagrams, or other documentation have been updated by the project team with experience
from post production support period.
Application data in the Baseline has been reviewed and all appropriate updates made
Appropriate monitoring of the application has been initiated.
Documentation has been reviewed and is acceptable for vendor to perform service
An updated FMEA is in place.
Support Engineers are entered into the tools (Contingent Worker data base, HPSD, SC, Kintana, Etc)
Disaster recovery documentation has been reviewed and found satisfactory, either by the BCP/DR team for SOx or
DR category 1 applications or by the AMS vendor for all others.
Source code responsibility has been transitioned from the development team to the AMS team.
For non standard technologies the vendor has reviewed the code and agrees that it is supportable.
Functional team has been provided vendor escalation process and vendor has received functional escalation
process from client.
Support team knows of no ongoing Reliability, Performance, Functional, or Deployment CTQ defects other than any
that have received an AMS exception.
Customer Leader Acceptance Sheet
Purchase order or other financial arrangements have been made with the PMO
(Program Management Office) team.
All required specification documents have been reviewed and are in the AMS
document repository
All AMS On boarding documents (SOW and Change Order) have been created
and are in the document repository
The application meets Performance, Reliability, Functional, and Deployment

requirements OR an AMS exception has been granted.
For legacy applications, a Legal Checklist review has been performed
Service request process has been explained to functional client and

arrangements to add the application to support list immediately prior to start of
support have been made.
Operational Readiness
The key activities is to evaluate the knowledge acquisition and the top issues with the following
topics are:
Service SLA OTD
Select the TOP 15% of the most ageing cases
Indicate the open average number of cases per week
Indicate the close average number of cases per week
Review the span, q1, q2, q3
Review the number of cases of backlog by service
Review the top week of cases of backlog
Validate the one enhancement with 12 steps and documentation required
SCR Workflow
Estimation Tool
Functional Requirement
Reception Checklist
Test Cases
Peer Review Checklist
Review Break/Fix TOP issues

Review the Technical Documentation up-to-date (7 Documents include communication plan)
Review the Complete RCA (Root Cause Analysis) for unplanned outages
Review the stability of the system and redirecting with the appropriate team if necessary
Review the CRUD and Complexity of the system components of the system
Review the quality of code (Code Review)
All Rights Reserved
Valores
Softtek S.A. de
C.V. 2011. Internal.
Review
theCorporativos
Configuration
Management
IM Owner On-Boarding Checklist

Functional owner is satisfied that knowledge transfer to the
AMS vendor has been completed to functional owners
satisfaction.
Performance of the application is acceptable and meet

minimum customer requirements
Reliability of the application has been demonstrated to be

acceptable
Application is green in Application Health Portal and meet

minimum customer requirements
Functionality meets the minimum expectations to allow the

application to be effectively used to perform the required
business function.
The application has been deployed to at least 1/3 of the

intended audience.
AMS team has provided its escalation process to the

functional owner and the function owner has provided their
required notification points to the AMS team
Knowledge Base and References

http://collaboration.softtek.com/practices/ams
Contact Information
Talent Development
AMS Training Program
AMS.Training@softtek.com

KnowledgeTransfer ENG

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

KnowledgeTransfer ENG

Caricato da

Copyright:

Formati disponibili

Knowledge Transfer

AMS Life Cycle

Process that allow to get Application Information

It belongs to Service Desing Phase

Knowledge Transfer Goal & Objectives

Define guidelines for transitioning applications in the AMS engagement from

Responsibilities for knowledge Transfer

Owner of the Application Activities

Strategy for Knowledge Transfer

Understand the Customer Priorities

Create and commit the KT Project Plan

Start Knowledge Management on applications

Status Meeting & Knowledge Evaluation

Sign off transitions

Take full ownership of

Deliver live according to

Transition Road Map

Setup near shore

Softtek Engineering Process

Evaluate actual K acquired

Evaluate results from the

Overall Process - Signoff & Move to

AMS Lead Sends a

Business Process Mapping

Leverage Clients for Functional Documentation

Deliverable Focused KT Sessions

Catchers can create Deliverables (at least draft versions at a minimum)

Document Validation Tool

At a minimum, capture Training Notes/Understanding Documents

Extra capacity for Incumbent resources

Business Modeling Business Process

Business Modeling System Context

Business Modeling System Context

Data and information sources all apps

Business Modeling Business Process

Kickoff Meeting Agenda

Operations: On-Boarding lead

The project team should be prepared to present the

Brief overview of the application

The support team will describe the following:

The Support document and the sourcing process

Softtek Acceptance Sheet

Customer Leader Acceptance Sheet

The application meets Performance, Reliability, Functional, and Deployment

For legacy applications, a Legal Checklist review has been performed

Service request process has been explained to functional client and

Review Break/Fix TOP issues

IM Owner On-Boarding Checklist

Performance of the application is acceptable and meet

Reliability of the application has been demonstrated to be

Application is green in Application Health Portal and meet

Functionality meets the minimum expectations to allow the

The application has been deployed to at least 1/3 of the

AMS team has provided its escalation process to the

Knowledge Base and References

Potrebbero piacerti anche