knowledgetransfer eng

All Rights Reserved Valores Corporativos Softtek S.A. de C.V. 2011. Internal.

Knowledge Transfer Process AMS Model 2.0


Fundamentals

AMS Life Cycle

Sibling Processes

Knowledge Transfer

Definitions

Goals and Objectives

Process

Steps

Risks

Knowlege Base & Other References

Agenda


AMS Life Cycle


Process that allow to get Application Information

from incumbent vendor to our organization.

Knowledge Transfer

It belongs to Service Desing Phase


Goals & Objectives

CSF

KPI

Goals

Objectives

To ensure all the information, applications, products are correctly delivered for

AMS starting.

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:

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

Knowledge Transfer Goal & Objectives


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

KT Risks


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


[email protected]

1 Prep. Meeting and Initial Kick-Off Meeting

2 Understand the Customer Priorities

3

Start Knowledge Management on applications

6

Tracking and Execute the KT Plan

7

Prioritizes the KT Plan base on criticality, and out coming vendor

Status Meeting & Knowledge Evaluation

8

Create and commit the KT Project Plan

5 Establish Risk Management

4

Sign off transitions

9

Strategy for Knowledge Transfer

Kickoff Meeting

Due diligence

10


Assessment

Knowledge

Transfer

Process &

Methodology

Tailoring

Parallel

Operation Operation

Transition

Process

Improvement

Service Level

Agreement

Monitoring

Transition

Out

Kick

Off

Assessment Operation

Tollgate 0 Tollgate 1 Tollgate 2

Sign off

RFP

Change

Request

GAP

Take full ownership of

knowledge and operation

Deliver live according to

SLAs and with productivity

gains

Understand AS IS and

make a diagnosis and

recommendation

Implementation Roadmap


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

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

Setup Environments Accesses

Pilot Operation 1 Primary support Incumbent Vendor Secondary support Softtek

Pilot Operation 2 Primary support Softtek Secondary support incumbent vendor

Process fine tuning Initial metrics Cross training Evaluate actual K acquired (gap)

Evaluate results from the gap analysis and define action items to follow Prioritize potential process improvement projects Take final ownership of on-going tasks Start execution of day to day tasks Start Service Management Knowledge Transfer Completed (Sign-Off) Finalize transition out of incumbent vendor process Parallel Support - Primary On Boarding Criteria(Go or not Go) Formalize Closing KT

Planing Knowledge

Acquisition

Parallel

Operation Operation

readiness

Transition Road Map


Overall Process - Signoff & Move to Steady State

KT Begins

Ready

for Stg 4

Stage 1

KT

Stage 2

Secondary

Support

Stage 3

Primary

Support

Docs Collected

Docs Read &

Reviewed

Docs Uploaded

Exit

Criteria

Updated

Track

Sheets

Incumbent

Agrees

Yes

Service

Manager

Agrees

Customer

Lead

Agrees

Yes Yes

AMS Lead Sends a

Note to Customer

confirming ready for

review

KT Manager

Initiate audit

process

Signoff

Sheets

Stage 4

Steady

State

Update Service

Manager

Lead Makes

Adjustments &

Repeats Signoff

Steps

Track Service

Manager and

Evaluate

Remediation

Reqd? Yes

Signoff NOT ok Signoff w/Gaps Signoff OK

Issue List Exceptions

KT Exit Criteria

Sec/Pri Support

Scorecards

Operation Plan

Quality Assurance

Business Process Mapping Operational Process


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

KT Planning


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)

Document Validation Tool


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

GAP Analysis


Subsystem B

System A

Collaboration Optimization WMS TMS Demand SFA

Supplier Manufacturing Distribution Wholesale/

Retail Consumer

Business Modeling Business Process


Inventory System

Suppliers

Sales Order

System

Warehouse

sales order

goods unavailable notice

purchase order

supplier delivery

shipping slip checked supplier invoice

Accounts

Department

goods returned

Business Modeling System Context example


QAM MDRS eNMS QEM

eCAM

QAS ePQAR Trigger

Tag Data

Collection

Generation based in

User Analysis

Only association

Automatic process

Relations

Source

Profiles ENACT EDSARS IMPACT

Calendar or

Perpetual Audit

Data and information sources all apps

eCAR

Business Modeling System Context Business Process Relations


1

2

3

1.1

1.2

System Context

Business Process HIGH Level

Business Process Second Level

Business Process

A B C D

Business Process

Relationships

Business Modeling Business Process Diagram Levels


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


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.

Softtek 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.

Customer Leader Acceptance Sheet


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)

Review the Configuration Management

Operational Readiness

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


http://collaboration.softtek.com/practices/ams

Knowledge Base and References


Contact Information

Talent Development AMS Training Program

[email protected]

knowledgetransfer eng

Documents

knowledge transfer plan

knowledge transfer commitment

retention knowledge

transition phase

mitigation plan

transition planning

ams engagement

inadequate transition