Six Sigma Project

© Copyright 2011 Tata Communications Ltd. All rights reserved. (Enter information) Topic | Title
Six Sigma Project for Cost Reduction/Process
Improvement for IP Provisioning

Tollgate Review DatesRoles and Responsibilities
Tollgate Date Signoff
Define
Measure
Analyze
Improve
Control
01-Feb-2016 02-Feb-2016
07-Feb-2016 09-Feb-2016
18-Feb-2016 20-Feb-2016
29-Feb-2016 29-Feb-2016
11-Mar-2016 16-Mar-2016
Team Vaibhav Agrawal,
Ananya Shukla,
Abhishek Gharge,
Aliya Shaikh
Process/Project coordinator Abhishek Gharge
Process Owner Vaibhav Agrawal
Black Belt /Process
Champion from TCS/Coach
-
Sponsor Kuldeep Jain
Stakeholders & Milestones

To investigate and to reduce the cost of the project by 10-15% (approx 1.5 to 2 lakhs for the current
project) by using SIX Sigma.
Scope
 Area of work is restricted to IP Address and no other inventory. It includes both Private & Public IP
allocation. It will be done both for V4 & V6.
 Work will be done only in module of IP Address allocation which is part of various inventory project
 Current network deployment supported within IMS system (Cramer)
Scope Exclusions
 Inventory other than IP Address
 Business processes or network implementations
Objectives
3

Goal is to reduce the cost of the IT project and to make the IP Allocation Rule Engine more efficient and
the target is to achieve this using Six Sigma.
Hard Dollar Savings
150000 to 200000 for this IT project (Cost savings will continue henceforth for all projects in future)
Other Benefits
Apart from the cost reduction, we will be using less human resource and human efforts plus the
completion of the project will take less time.
Project Goal
4

Define

After the brainstorming session within the team, the main factors that identified for increased efforts
towards new developments/modification in IP Rule engine are:
• Dynamic business and network in TCL
• Changing requirements after shared with IT
• Software design
• Software development
• Software testing
We have used the Interrelationship Diagraph to find impact of these main causes and derived that
the software design, thus development and thus testing are all equally complex and interdependent.
Further, as this engine allocates IP Address to customer which is an integral part of all the Layer-3
services being offered by TCL, we see a substantial opportunity in this area and thus have decided to
use Six Sigma to achieve the goal.
We have estimated a cost saving of around 1.5 to 2 lakhs INR in an ongoing project which is
around this engine. Also the benefits will continue for the upcoming projects around this module.
The plan is to complete the MEASURE phase and confirm whether the steps/factors that we have
listed in define phase are valid and correct to progress.
Define in a nutshell
6

Interrelationship Diagraph
7

© Copyright 2011 Tata Communications Ltd. All rights reserved. 8
DMAIC: Measure
IPRule Engine

There are various ways to approach effort estimation. On a very broad level, below are the categories:
 Expert estimation: The quantification step, i.e. the step where the estimates (effort) are derived based on
domain/technical expertise and prior project experiences. This also has gut element attached to it.
 Formal estimation model: This quantification step is based on mechanical processes, for e.g. use of a formula
derived from historical data
 Combination-based estimation: This quantification step is based on a combination of judgmental and mechanical
estimates.
Methods/Approaches for Effort Estimation:
9

“Best Approach”: Differences in estimation accuracy of different estimation approaches and models suggest that there is
no best method per se. Relative accuracy of one approach in comparison to another depends strongly on the context.
 Expert estimation is on normally as accurate as some model-based effort estimation technique.
 In certain situations or business cases, where relationships between parameters and parameters used in the model
are not present, expert estimation is most suitable.
 Formal estimation models are not tailor-made for any particular company demands or models, and thus may not fit
every time.
 Also can be a case where a defined estimation model is perfectly suitable for a project and specially as the experts
estimates are perhaps subjective.
 In forecasting domains - the most robust finding, is that combination of estimates from independent sources,
preferable applying different approaches, will on average improve the estimation accuracy.
We have also considered other factors such as ease of understanding and communicating the effort derivations to
business, training and cost attached to usage of a specific model/tool and finally for accounting the hidden requirements
in the projects.
We thus use Expert estimation approach for any project effort estimations.
Selection of suitable estimation approach:
10

We have calculated total efforts for 3 projects delivered in past. The data is represented in the above figure.
Data collection and validation
11

Case 1:
 We have considered efforts which is number of days
required for development. In case 1 this is 155.
 From past experience, designing would need 31 days i.e.
say approximately 20%.
 System Integration testing phase has more effort
associated. Say roughly ~30%. i.e. ~46.5 days.
 In User acceptance testing we deliver the project and the
user is testing the functionalities. Since one level of
testing is already closed, this will ideally require lesser
time. Say 10%. So, 15 days.
 Next is Production Release, where we release the project
in live environment for the business / client. For this we
have approx. 20 days i.e. roughly 10-15%.
 So, total effort is total summation i.e.~267.5
12

DMAIC: ANALYSE
IPRule Engine

A cause and effect diagram also known as the “fishbone” diagram is the best
representation to showcase the Analysis phase is of this project, which in turn can
help in brainstorming to identify possible causes of a problem and in sorting ideas
into useful categories. A fishbone diagram is a visual way to look at cause and effect.
Approach for Analyse Phase: Fishbone Diagram
14

© Copyright 2011 Tata Communications Ltd. All rights reserved. (Enter information) Topic | Title 15
Cause-Effect Analysis for high development
cost:

Problem statement: High Development Cost
Major categories of causes of the problem: Skill, Dynamic Business, TAT, Risk Aversion
The below causes adds to the high IT development cost:
1. SKILL : When a new system is being introduced, a skilled/Trained professional, domain experts etc. are required
which added to the high development cost.
2. Dynamic Business: In a dynamic industry like Telecom, new product launches are very frequent and which further
has various variants coming into picture. This leads to continuous changes in the IT SYSTEM architecture. Thus
impacts the modularity and design of IT code base.
3. TAT Pressure ( Turnaround time for a service): There are various small fixtures/developments which may take a
small amount of IT development time and thus needs to be taken up on high priority. Thus, there are mostly done
without understanding an E2E impact. Many such frequent additions ultimately may break the code design, its
modularity and may end up containing lots of redundancy. Thus further new addition makes it more complex and
increases the cost of development.
4. Risk aversion: A normal development tendency is to create a new code base for incorporating a new feature. This
is to avoid an undue risks on the running piece. This again breaks modularity and redundancy creeps in.
16
Fishbone Diagram - Elaborated

DMAIC: IMPROVE
IPRuleEngine

• Post ANALYSE phase, we have identified various factors which finally lead
to cost of development for a new project or modification in existing rules of
IP Rule engine.
• Using DOE, we have categorized these factors into controllable and
Uncontrollable input factors.
 Controllable input factors are the input variables that can be modified in
an experiment or process. It is these factors were MAJOR
concentration will be in IMPROVE phase.
 Uncontrollable input factors are those parameters that cannot be
changed and controlled.
 Responses also called as output measures, are the elements of the
process outcome that gage the desired effect.
DOE to determine KPIV:
18

DOE to determine KPIV contd..
19
IP Allocation
Rule
 Design
 Modularity
 Code Tuning
 Hidden requirements
 Dynamic Business needs
 Reduced design and
development efforts
 Reduced testing efforts

 Modified the code base and made it more modular based of logical
functional blocks
 Replaced traditional methods of implementation with OOB available
product features
 Fine tuned code:
Fine tune logic of expected IP count Vs Actual IP count. This
particular block is very complicated and thus makes new logic changes
and new development very difficult from design and development
perspective.
Code refining will be done using new Work order functionality and
removing this old implementation.
This has resulted in removal of ~500 Lines of code and complex IF…
ELSE conditions.
 With this implementation, even the testing effort has come down
drastically.
Steps Implemented:
20

 The estimated effort vs Actual effort for the ongoing project
was reviewed.
 With this implementation, the actual efforts were reduced by
count of approximately 35-40 Man days.
 Due this effort/cost saving, actual development team was
able to take up additional required without any cost
implications.
 So in effort brought a saving of ~ 1.5 L INR or delivery of
addition business needs without any extra costs.
Evaluation:
21

Visit tatacommunications.com
Thank You

Six Sigma Project

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (6)

Ähnlich wie Six Sigma Project

Ähnlich wie Six Sigma Project (20)

Six Sigma Project