Chapter 4
CHAPTER 4.0
RESULTS AND DISCUSSIONS
4.1. Defect Causal Analysis
The endeavor is to expose and analyze the key areas of the implementation process
and procedure for various kinds of problems and other human factors which
contributes to the end result of an unsuccessful implementation.
Hence a Defect Causal Analysis was carried out which highlighted the root causes
which had a major contribution in the problems that both the client as well as the
vendor faced during the course of the ERP implementation procedure. Defects are
analyzed to determine the cause of an error .The major root causes were classified
into four sub-headings namely, the ERP Package itself, its application, the top
management and finally the data collection. The main effect was the challenge faced
in the implementation of the ERP system.
The quality issues were segregated on the basis of the module in which they
originated and the frequency with which they occurred in these modules (Refer
Annexure 1). The complete issue list was then considered for further analysis by
means of a Pareto Chart using tools. The major benefit of using this type of an
analysis was to get the client to concentrate on just the vital few problems from the
complete issue list that was recorded. This enabled a deep and thorough analysis of
problems encountered in implementation so that a concentrated study might be
carried out.
Table 4.1: Number of issues in each module
Bin No of Error Cumulative %
SD 53 40.45802
FI-CO 35 67.17557
MM 25 86.25954
HR 10 93.89313
PP 4 96.94656
BASIS 4 100
Pricing, 22
Improper definitions ,
18
Account assignment,
11
Fig. 4.1: Pareto chart- Implementation issues in each module
From the analysis by means of the Pareto Chart, it was found that the functional
modules of Sales & Distribution and Financial-Control posed majority of the
problems. Hence, these problems needed to be addressed through a more precise tool
which will bring out the exact areas of shortcomings in the whole system. This was
achieved through a Cause & Effect Diagram assessing the main effect that was the
major bottlenecks at the company.
I. Sales and Distribution Module
Table 4.2: Sales and Distribution frequency table
Sl. No Causes of problems Frequency
1 Pricing 22
2 Improper definitions 18
3 Account assignment 11
Fig. 4.2: Pie-chart for Sales and Distribution Module
53
35 25
10 4 4
0
50
100
0
20
40
SD FI-CO MM HR PP BASISEr
ror
Fre
qu
en
cy
Modules
Pareto Analysis
Frequency Cumulative %
II. Why-why analysis for the Major bottle neck
Major problem areas observed by Pareto Chart are Sales and Distribution Module
contributing 41% and the Financial Accounting and controlling module contributes
27% summing together becomes 68% of the total problems facing in ERP transaction.
1. Sales and Distribution Module - In this module we observed 53 defects out of
131, defects were such as Error in Delivery Challan, No accounting document
creating, Credit limit verification and so on, these defects causing errors in
functioning of ERP systems. The defects were present in the module due to below
identified reasons
Pricing - It was observed that there was no standardized pricing procedure
which resulted in incorrect pricing.
Improper definition - It was noticed that there was incomplete sales areas
definition in turn yielded in loss of controls.
Account Assignment - It was observed in effective account assignment due to
improper accounting system which has root to wrong financial posting.
II. Financial Accounting and controlling module
Table 4.3: Financial Accounting & Control frequency table
Sl. No Causes of problems Frequency
1 Masters 12
2 Tax schema 10
3 Asset management 8
4 Improper definitions 5
Masters 34%
Tax schema 29%
Asset management
23%
Improper definitions
14%
Fig. 4.3: Pie-chart for Financial Accounting and controlling Module
Why-why analysis for the Major bottle neck
2. Financial Accounting and controlling module - In this module we observed 35
defects out of 131, defects were such as Tax payment errors, sales promotion
exception posting, changing reconciliation account and etc, these defects impacted
functioning of Financial Accounting and controlling module . The defects are
confronted due to following reasons.
Masters - It was observed that there was a mismatch between balance sheet
and trial balance, accounts codes were not matching resulted in improper
maintenance of master data base.
Tax schema - In the Taxing system there is lot of variations due to taxing
policies followed by different states as well as countries such as variations in
Value Added tax (VAT), sales tax and other commercial taxes resulted in
wrong tax calculation and wrong ledger posting.
Asset management - It was observed that there was improper asset register
and depreciation calculation resulted in incomplete asset classification and
finally resulted in improper asset management.
Improper definition - It also noticed that there was no standardized financial
control and procedure followed.
Table 4.4: Why-why analysis for SD & Fi-CO
Sl
No.
Problem Cause Root cause Solution
1 Major
bottle neck
SD 1. Pricing
2. Improper
definition
3. Account
Assignment
Standardize pricing procedure.
Redefine sales areas.
Formulate standard accounting
system.
FI-CO 1. Masters
2. Tax schema
3. Asset
management
4. Improper
definition
Review software architecture.
Regularize ledger posting.
Standardize asset classification.
Standardize Financial controls
and procedure.
Fig 4.4: Ishikawa diagram to identify the bottleneck
Finance and
control
Sales and Distribution
P1-Pricing
Correct pricing
procedure
Wrong pricing
Wrong sales area
Definitions
Loss of controls
P3-Account Assignment
Improper account
Wrong FI Postings
P1-Masters
Account codes Wrong Balance Sheet
Trial Balance
P3-Asset management
Incomplete Asset
Classification
Improper asset
Register and Depreciation
calculation
P2-Tax Schema
P4-Improper definition
Wrong tax calculation &
FI Postings
P2-Improper definition
Major
bottlenecks
4.2. Grounded Theory: Factors identified.
Grounded Theory “A theory is inductively derived from the study of the phenomenon
it represents. That is, it is discovered, developed, and provisionally verified through
systematic data collection, analysis, and theory stand in reciprocal relationship with
each other. One does not begin with a theory, and then prove it. Rather, one begins
with an area of study and what is relevant to that area is allowed to emerge”. GT
differs from other qualitative approaches. Traditional qualitative approaches collect
the data first before commencing the analysis and long after they have left the
research site. In contrast, grounded theorists use their emerging theoretical categories
to shape the data collection while doing the fieldwork. The data analysis followed
three types of coding; open coding, (b) axial coding, and (c) selective coding
(a) Open coding : From the literature, readings on theory, research, and supporting
evidence the theoretical sensitivity can be broadly classified into four categories
namely organizational critical success factor, Tactical critical success factor,
Technological critical success factor and the Strategic critical success factor. The
relationship between the category, Properties and Dimensions are identified.
(b) Axial coding: here we established the relationship between the categories obtained
during open coding.
(c) Selective coding: here the central category and the linking category are decided, in
our study, the central category will be Successful ERP Implementation, other
categories that were considered to influence the central category is integrated as the
intervening factors. The result of the tasks is the theoretical scheme, which is
subjected to further analysis
Fig. 4.5: Factors affecting ERP implementation
4.3. Analytical Hierarchy Process (AHP): Prioritized the factors
4.3.1. Structure of AHP model for ranking and comparison
The reason for choosing this model is the fact it consists of a great number of criteria,
not all of which of the same importance. In addition to this, a high quality computer
system/software Super Decision has been developed. It is used in assisting the
development of the model and enables a detailed sensitivity analysis of the final
ranking list on the change of the values which are assessed subjectively.
In order to use this model for ranking, we need to determine the weights of the main
criteria and sub-criteria, and then for each.Criteria at the bottom level of the hierarchy
structure to define the intensities for the evaluation of the relevance. The weights of
criteria and sub-criteria are calculated by the help of Super Decision software on the
basis of the pair wise comparison of relative criteria and sub-criteria importance. For
quantity criteria, the intensities are defined on the basis of the five-level scale of
intensities (excellent, very good, good, satisfactory, weak), which have been derived
on the basis of the range in which their values have fluctuated.
ERP
Implementation
Consequences
Organizational
CSFs
Tactical
CSFs
Strategic
CSFs
Consequences
Never run
Parallel
sysytem
Adequate and
Correct Data
Stakeholders
Identification
Training and
Testing Conference Room
Pilot
Customization
Clarity In mngt
objective
Employee Retention
Technologic
al CSFs
Step 1 - Determination of the relative importance of the attributes
Fig. 4.6: Screen shot: Determining important attributes
Step 2 - Determination of the relative importance of each of the alternatives with
respect to each attribute. Determine the overall priority weight of each of these
alternatives.
Fig. 4.7: Screen shot: Relative importance of attributes
Step 3 - The next step is to evaluate all the choices on each objective.
Fig. 4.8: Screen shot: Evaluate attribute choices
Step 4 - The priority value is now calculated with the help of relative scores tables
and the weights of the objectives.
Fig. 4.9: Screen shot: Priorities attributes
The following are the response obtained from The Questionnaires were asked to
Consultants and user which gave both quantitative issues encountered in
implementation of the ERP system the response is follows.
Table 4.5: Response prioritization matrix
Factors Response
1 2 3 4 5 6 7 8 9 10
Adequate and
Correct Data 0.292 0.301 0.290 0.302 0.294 0.311 0.296 0.313 0.326 0.323
Training and
Testing 0.136 0.146 0.139 0.140 0.140 0.143 0.134 0.139 0.130 0.127
Never run
Parallel system 0.160 0.150 0.160 0.158 0.156 0.151 0.157 0.153 0.154 0.157
Conference
Room Pilot 0.087 0.080 0.082 0.081 0.085 0.083 0.084 0.087 0.086 0.085
Employee
Retention 0.089 0.083 0.086 0.084 0.086 0.081 0.084 0.085 0.087 0.085
Customosation 0.084 0.084 0.084 0.084 0.082 0.081 0.086 0.083 0.083 0.082
Clearity In
management
objective
0.107 0.112 0.115 0.106 0.112 0.103 0.114 0.095 0.091 0.138
Stakeholders
Identification 0.044 0.044 0.045 0.044 0.044 0.047 0.045 0.047 0.044 0.005
4.4. Hypothesis testing: Accepting or rejecting the null hypothesis.
Since the sample size is small and the population variance is unknown‘t’ test is
performed on the hypothesis.
0.28 0.29 0.30 0.31 0.32 0.33
ADEQUATEAND
0
1
2
3
4
Co
un
tI. Null: there is no significant difference between the sample mean and the population
mean.
II. Alternate: there is significant difference between the sample mean and the
population mean.
For Adequate correct data to the consultant factor the mean computed to be x bar =
0.304 The Null Hypothesis Ho: µ=0.304. And alternate hypothesis Ha: µo ≠ 0.304.
The test statistics using the data for the first value tComputed = x -0.340/(SD/SQRT(n))
Where x is the mean SD is the standard deviation.
n is the sample size.
Since there are 10 data points sample size is 10.
Degree of Freedom (DOF) =n-1=10-1=9.
Level of significance assumed is 5%.
Sine it is two tailed test we use α/2=0.025.
tCalculated =0.137
The critical value to compare this value against is ttabulated = t10-1,0.025 =2.26, since
tcalculated is within the interval (-2.26,2.26).the hypothesis cannot be rejected. The
corresponding p-value p(xbar>0.137)= 0.894 for us to reject the hypotheis the p-value
should be less than 0.05. Similarly the 95% CI t vaule p value are calculated using
SYSSTAT software and the results are as follows.
1
Likewise we have tested the hypothesis for other factors also and the resultsa are
tabulated as follows.
One-sample t test of ADEQUATEAND with 10 cases;
Ho: Mean = 0.304
Mean = 0.305 95.00%
CI = 0.295 to 0.314
SD = 0.013
t = 0.137
df = 9 Prob = 0.894
Fig. 4.10: Box plot: Adequate and correct data to consultant
One-sample t test of TRAININGAND with 10 cases;
Ho: Mean = 0.137
Mean = 0.137 95.00%
CI = 0.133 to 0.142
SD = 0.006
t = 0.141
df = 9 Prob = 0.891
Fig. 4.11: Box plot: Training
One-sample t test of NEVERRUNPA with 10 cases;
Ho: Mean = 0.155
Mean = 0.156 95.00%
CI = 0.153 to 0.158
SD = 0.004
t = 0.509
df = 9 Prob = 0.623
Fig. 4.12: Box plot: Parallel system
One-sample t test of CRP with 10 cases;
Ho: Mean = 0.084
Mean = 0.084 95.00%
CI = 0.082 to 0.086
SD = 0.002
t = -0.011
df = 9 Prob = 0.991
Fig. 4.13: Box plot: Conference Room Pilot
0.150 0.152 0.154 0.156 0.158 0.160 0.162
NEVERRUNPA
0
1
2
3
4
Co
un
t
0.12 0.13 0.14 0.15
TRAININGAND
0
1
2
3
4
5
6C
ou
nt
0.079
0.080
0.081
0.082
0.083
0.084
0.085
0.086
0.087
0.088
CRP
0
1
2
3
Co
un
t
0.081
0.082
0.083
0.084
0.085
0.086
0.087
0.088
0.089
EMPLOYEERET
0
1
2
3
4
Co
un
t
0.081 0.082 0.083 0.084 0.085 0.086
CUSTOMOSATIO
0
1
2
3
4
Co
un
t
One sample t test of EMPLOYEERET with 10 cases;
Ho: Mean = 0.085
Mean = 0.085 95.00%
CI = 0.084 to 0.086
SD = 0.002
t = -0.054
df = 9 Prob = 0.958
Fig. 4.14: Box plot: Employee retention
One-sample t test of CUSTOMOSATIO with 10
cases; Ho: Mean = 0.083
Mean = 0.083 95.00%
CI = 0.082 to 0.084
SD = 0.001
t = 0.238
df = 9 Prob = 0.817
Fig. 4.15: Box plot: Customisation
One-sample t test of CLEARITYIN with 10
cases; Ho: Mean = 0.109
Mean = 0.109 95.00%
CI = 0.100 to 0.119
SD = 0.013
t = 0.118
df = 9 Prob = 0.908
Fig. 4.16: Box plot: Clarity
0.09 0.10 0.11 0.12 0.13 0.14
CLEARITYIN
0
1
2
3
4
5
6
Co
un
t
0.00 0.01 0.02 0.03 0.04 0.05
STAKEHOLDERS
0
2
4
6
8
10
12
Co
un
t
One-sample t test of STAKEHOLDERS with
10 cases; Ho: Mean = 0.046
Mean = 0.041 95.00%
CI = 0.032 to 0.050
SD = 0.013
t = 0.019
df = 9 Prob = 0.985
Fig. 4.17: Box plot: Stake holder
Table 4.6: Hypothesis Test summary
Sl.
No
Factors Null
Hypothesis
Alternative
Hypothesis
95.00%
CI
t Prob Result Null
Hypothesis
1. Adequate and
Correct Data to
consultant
μ0=0.304
μa≠0.304
0.295 to
0.314
0.137 0.894 Donot
Rejected.
2. Training and
Testing
μ0=0.137 μa≠0.137 0.133 to
0.142
0.141 0.891 Donot
Rejected.
3. Never run
Parallel
sysytem
μ0=0.155 μ0≠0.155 0.153 to
0.158
0.509 0.623 Donot
Rejected.
4. Conference
Room Pilot
μ0=0.084 μ0≠0.084 0.082 to
0.086
-.011 0.991 Donot
Rejected.
5. Employee
Retention
μ0=0.085 μ0≠0.085 0.084 to
0.086
-0.05 0.958 Donot
Rejected.
6. Customosation μ0=0.083 μ0≠0.083 0.082 to
0.084
0.238 0.817 Null
Hypothesis
Donot
Rejected .
7. Clearity In
mngt objective
μ0=0.109 μ0≠0.109 0.100 to
0.119
0.118 0.908 Donot
Rejected .
8. stakeholders
Identification
μ0=0.046 μ0≠0.046 0.032 to
0.050
0.019 0.985 Donot
Rejected .
Table 4.7: Rank allocation for influencing factors
Factors Priority
value Percentage %
Priority
/Rank
Adequate and Correct Data to consultant 0.304 30.4 1
Training and Testing 0.137 13.7 3
Never run Parallel system 0.155 15.5 2
Conference Room Pilot 0.084 8.4 6
Employee Retention 0.085 8.5 5
Customosation 0.083 8.3 7
Clearity In mngt objective 0.109 10.9 4
stakeholders Identification 0.046 4.6 8
Fig. 4.18: Force Field diagram for successful ERP implementation
4.5 Force Field Analysis: Explored restraining forces.
From the force field analysis it was found that the role of consultants and the
customer dominates, 38.7% and around 30% respectively.
These major restraining force was further considered for analysis to improve ERP
implementation successfully.
4.6. Gap with respect to CMMI.
The final gaps are sorted into categories and listed as shown below:
Presen
t State
Desired
State
Consultant – 30.4 %
Training & Testing -13.7%
Parallel System – 15.5 %
Conference Room Pilot -8.4
%
Employee Attrition – 8.5 %
Customization – 8.3 %
Organization Culture – 10.9 %
Employees Exclusiveness -4.6 %
Customer Demand
Order acceptance
Increase Productivity
Trust in Team leader
Driving Forces
Positive forces for change
Restraining Forces
Obstacles for change
Fig. 4.19: Integrated Project Management
Fig. 4.20: Measurement and Analysis
Fig. 4.21: Organizational process definition
SG 1 SG 2 SG 3
CMMi 6 3 5
NGDM 2 2 2
0
1
2
3
4
5
6
7
Spe
cifi
c P
ract
ice
by
Go
als
SG1 SG2 SG3
CMMI 3 3 2
NDGM 2.5 3 2.5
0
0.5
1
1.5
2
2.5
3
3.5
Spe
cifi
c P
ract
ice
by
Go
als
SG 1 SG 2 SG 3
CMMi 6 3 5
NGDM 2 2 2
0
1
2
3
4
5
6
7
Spe
cifi
cPra
ctic
e b
y G
oal
s
Fig. 4.22: Organizational process focus
Fig. 4.23: Organizational Training
Fig. 4.24: Product Integration
SG 1 SG 2 SG 3
CMMi 6 3 5
NGDM 2 2 2
0
1
2
3
4
5
6
7
Spe
cifi
c P
ract
ice
by
Go
al
SG1 SG2
CMMI 4 3
NGDM 3 3
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
Spe
cifi
c P
ract
ice
by
Go
al
SG1 SG2 SG3
CMMI 3 2 4
NGDM 2 2 3
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
Sp
eci
fic
Pra
ctic
e b
y G
oal
Fig. 4.25: Project Monitoring and control
Fig. 4.26: Project planning
Fig. 4.27: Process and product quality assurance
SG1 SG2
CMMI 7 3
NGDM 6 2
0
1
2
3
4
5
6
7
8
Spe
cifi
c P
ract
ice
by
Go
als
SG1 SG2 SG3
CMMI 4 7 3
NGDM 4 6 3
0
1
2
3
4
5
6
7
8
Spe
cifi
c P
ract
ce b
y G
oal
s
SP1 SP2
CMMI 2 2
NGDM 2 1
0
0.5
1
1.5
2
2.5
Spe
cifi
c P
ract
ice
by
Go
als
Fig. 4.28: Requirement development
Fig. 4.29: Risk Management
Fig. 4.30: Supplier Agreement Management
SP1 SP2 SP3
CMMI 2 3 5
NGDM 2 2 6
0
1
2
3
4
5
6
7
Sp
ecif
ic P
ract
ice
by
G
oa
ls
SG1 SG2 SG3
CMMI 3 2 2
NGDM 1 1 1
0
0.5
1
1.5
2
2.5
3
3.5
Spe
cifi
c P
ract
ice
by
Go
als
SP1.1 SP1.2 SP1.3 SP2.1 SP2.2 SP3.1 SP3.2
CMMI 33 33 33 50 50 50 50
NGDM 5 8 5 5 5 5 5
0
10
20
30
40
50
60
Spe
cifi
c P
ract
ice
by
Go
als
Fig. 4.31: Technical solution
Fig. 4.32: Validation
Fig. 4.33: Verification
CMMI0
1
2
3
4
SG1SG2
SG3
Spe
cifi
c p
ract
ice
by
Go
als
CMMI
NGDM
0
1
2
3
4
SG1SG2
SG3
Spe
cifi
c p
ract
ice
by
Go
als
SG1 SG2 SG3
CMMI 2 4 2
NGDM 2 3 2
SG1 SG2 SG3
CMMI 2 4 2
NGDM 2 3 2
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
Spe
cifi
c p
ract
ice
by
Go
als
Table 4.8: Review of process area gap analysis
Sl. No Process areas Specific goals TOTAL No. of gaps
1. REQM 1.5 5 1
2. PP 1.4,2.7,3.3 14 5
3. PMC 1.7,2.3 10 2
4. CM 1.3,2.2,3.2 7 4
5. PPQA 1.2,2.2 4 1
6. MA 1.4,2.4 8 2
7. RD 1.2,2.3,3.5 10 2
8. TS/SAM 1.3,2.5 8 0
9. PI 1.3,2.2,3.3,3.4 12 3
10. VAL 1.3,2.2 5 2
11. VER 1.3,2.3,3.2 8 3
12. IPM 1,6,2.3,3.5 14 5
13. RSKM 1.3,2.2,3.2 7 5
14. OPF 1.3,2.2,3.4 9 0
15. OPD 1.5,2.3 8 0
16. OT 1.4,2.3 7 0
17. DAR 1.6 6 5
TOTAL 142 40
Gaps analysis based on the Total Number of gaps in the various process areas. The
weightage factor is used to correct disproportional sample sizes and adjust the
collected data to represent the population from which the sample was drawn the
average factor is the rounded off to
Table 4.9: Weightage factor allocation for process area
Sl.No Process Areas No. of gaps Weight age
Factor
Average gaps in
each areas
1. REQM 1 0.25 0
2. PP 5 0.25 1
3. PMC 2 0.03 0.2
4. CM 4 0.06 0.12
5. PPQA 1 0.03 0.01
6. MA 2 0.03 0.04
7. RD 2 0 0.06
8. TS/SAM 0 0 0
9. PI 3 0.15 0.03
10. VAL 2 0.02 0.06
11. VER 3 0.02 0.06
12. IPM 5 0.15 1
13. RSKM 5 0.01 0.75
14. OPF 0 0 0
15. OPD 0 0 0
16. OT 0 0 0
17. DAR 5 0.25 1
40
To determine the percentage of gap in each processing areas:
Table 4.10: Gap analysis in percentage for process areas
Sl.No Processs Areas No. of gaps Percentage
1 Risk Management-RSKM 5 12.5
2 Project Planning -PP 5 12.5
3 Integrated Project Management -IPM 5 12.5
4 Decision Analysis and Resolution-DAR 5 12.5
5 Configuration Management-CM 4 10
6 Verification-VER 3 7.5
7 Product Integration-PI 3 7.5
8 Validation-VAL 2 5
9 Measurement and Analysis -MA 2 5
10 Requirements Development-RD 2 5
11 Project Monitoring and Control -PMC 2 5
12 Requirements Management-REQM 1 2.5
13 Process and Product Quality Assurance -PPAQ 1 2.5
Fig. 4.34: Process area gap in percentage
Risk Management-RSKM
1%
Project Planning -PP 3%
Integrated Project
Management -IPM 4%
Decision Analysis and Resolution-DAR
6%
Configuration Management-CM
7%
Verification-VER 8%
Product Integration-PI 9% Validation-
VAL 9%
Measurement and Analysis -MA
10%
Requirements Development-RD
10%
Project Monitoring and Control -PMC
11%
Requirements Management-REQM
11%
Process and Product Quality Assurance -
PPAQ 11%
Table 4.11: Pareto analysis table
Sl.
No
Process Area of CMMI No. of
gaps
Percentage Cumulative
%
1 Risk Management-RSKM 5 12.5 12.5
2 Project Planning -PP 5 12.5 25
3 Integrated Project Management -IPM 5 12.5 37.5
4 Decision Analysis and Resolution-DAR 5 12.5 50
5 Configuration Management-CM 4 10 60
6 Verification-VER 3 7.5 67.5
7 Product Integration-PI 3 7.5 75
8 Validation-VAL 2 5 80
9 Measurement and Analysis -MA 2 5 85
10 Requirements Development-RD 2 5 90
11 Project Monitoring and Control -PMC 2 5 95
12 Requirements Management-REQM 1 2.5 97.5
13 Process and Product Quality Assurance -
PPAQ
1 2.5 100
Fig. 4.35: Pareto chart for identifying critical process area
Based on the weighted, Percentage of Gap and the pareto Analysis the major gap
found in the Risk Management, Project Planning ,Integrated Project Management and
Decision Analysis and Resolution and the corrective action is taken up.
0
20
40
60
80
100
120
Percentage
CUMULATIVE %
4.7. Closer of the gaps: Bridging the gap between NDGM and CMMI.
The gaps in the process areas of NGDM are identified and the major gaps found in the
risk management, project planning, integrated project management decision analysis
and resolution process areas
4.7.1. Risk Management-RSKM
Risk analysis was not done,Risk is what happens unexpectedly and affects the flow of
operations while they are going on. So, to minimize the effects of risk, they are pre
determined or expected and safety measures will be taken.
In this project risk analysis was not done. There was one risk of hierarchy changing
many times. The hierarchical structure of DM changed for 15 times. As hierarchy has
very intense effect on DM, it could had been analyzed before only and safety
measures like specifying the customer the exact number of hierarchical changes
possible and could have told that any further changes would be treated as customer
request and would have got compensation. There were hierarchical changes in
prototype 1 and even in prototype 2 also.
The Spiral SDLC, which NGDM advocates emphasizes on risk analysis during each
spiral. The project team has started to document the risks at each spiral/milestone and
having a formal risk response plan associated with it. By repeatedly following a
rigorous risk analysis the preparedness to solve problems will be considerably
increased.
Prototype 2 typically consists of following activities:
Get feedback from prototype 1
Modify Data model design based on feedback
Integration design
Design of Non-out of the box workflows
Design Job Scheduler
Design test specifications for production data set
Data model creation as per design
Integration development
Configure, build and test various functionalities in the solution
Development of Non-out of the box workflows
Develop job scheduler
Prepare and Build test cases with production data set
Periodic Build and Test cycles with production data set
Reviews with customer
The risk template filled for February is as follows
Table 4.12: Risk template
Project Code :
Sl.
No.
Category Risk Consequences Date
Identified
Impact Impact of
Risk Value
Risk
Response
Type
1 Customer Risks Resistance to
change/acceptance of new
ways of working
Company product will not be
completely installed at customers
place. So, the efforts of developing
the product would be waste
25-Feb-2*** Medium Low Mitigation
2 Customer Risks Buy-in of ST organization
for the Roll-Out – project
is focused on Phase 1
scope only, including
makeup of Project Board
Only few advantages of the product
are gained. Product is not fully
utilized at the customer place and
almost same consequences of the
previous risk.
25-Feb-2*** Low Medium Mitigation
3 Resource Risks Availability of project
resources – ST resources
are not assigned full time
on the project and have
other project/operational
roles
Consultants who are multiplexed
would find lesser time in any one of
projects due to over time in one of
the projects. So he may not be
available for work. And this will
cause delay in current project
because there may be some
operations which would only
proceed after his work.
27-Feb-2*** Medium Medium Mitigation
4 Implementation
Risks
Integration with
downstream systems –
changes may be required
to MFS/DMT, E2
scheduling,
BM/DRP/SGA06
Integration time will be delayed,
overall project will not be completed
in time.
28-Feb-2*** Medium Low Mitigation
Statement Of Work(SOW) which is the basic thing that is very necessary for every
project and this statement specifies about the work to be done in the project. The
project manager after properly analyzing the work to be done will prepare the
statement and there will be an official sign off by the customer which is the indication
of proceeding with work. Sometimes there can be even negotiations after sign off
also.
Because of not doing risk analysis in SOW it can be at least stated that there could be
probability of occurrence of risk and time could had been taken for that.
Table 4.13: Statement of work
Response Priority Risk
Score
Risk
Owner
Have a formal training plan and train the customer
about the product and making customers realize the
advantages and ease of using the new product.
Medium 0.2 Project
manager
Have an adequate training and workshop sessions.
Training should make sure that everyone in the
company will be ready to accept the product.
Training should be done in more sessions and this
will reduce the risk.
Medium 0.3 Project
manager
Consultants working for the project should be out of
other projects and if the employee is multiplexed his
other job should not affect the current project.
Medium 0.6 Project
manager
We should ask customer to explain their system so
that we can plan according to it.
Medium 0.2 Project
manager
In the same way the risk template was filled March and April also. By taking action
according to response, the risks were minimized. There was one more risk added in
the March template which is the drastic changes in the hierarchy. Its priority was high
and even it was resolved to medium. One of the above four risks which is the risk of
available resources couldn’t be resolved till May; its priority was left out at medium
only.
4.7.2. Project Planning –PP
From the estimation you can just think about how many days each activity would
take, where as in base lining we will finally fix the number of days the activity should
take and base lining basically means setting up the dead line of those activities by
when they should be finished.
The schedule variance metrics is got from the MS project:
The screen shot MS project is as shown below, Project focused on processes rather
than functionality:,The focus of project members was mainly on how the forecasting
processes are to be handled rather than going into the technical part of building the
functionalities for the project as well. If there was focus on functionality and the
technical aspects the project could have got many reusable components in the DM
when the hierarchies are changed and this would have saved the precious time of the
team. This would have reduced some burden on the employees. DM projects are
Integration intensive and hence postponing the integrations to a later stage affected it
severely.
Fig. 4.36: Screen shot: Project planning
The the above Project plan it is found that the schedule variance is 2 weeks delay. For
some security reason the company didn’t let us put the network diagram.
Effort variane = -9%
Schedule variance = 2 weeks delay
when you look at schedule variance it is 2 weeks delay which is a very bad negative
effect and which adds for cost of the project for the company.
If the team had followed template and had done risk analysis at the right time, they
could have saved lot of time and even if there was any possibilities of delay, they
could have been shown it to the customer.
I. Time sheets data and project metrics: Use Time sheets data and Project plan in
MS project for making the project metrics.
By the timesheets data we will know in detail about each person working in the
project, about the no. of hours he has worked in the project and the time expend type,
that is, what kind of activity he or she was involved while doing the project. By this
we will calculate the total full time efforts (FTEs) put by the team members in the
project. Full time is 8 hours per day.
For 121 days in our project, 121*8= 1 full time effort for 121 days.
121 days are from the start date 26-Nov-08 to date of review 15-May-08.
Effort variance is calculated by formula:
Effort variance = (Estimated effort-actual effort)/ Estimated effort*100
The Effort variance metrics is as shown below:
Table 4.14: Effort variance matrix
Sl
No.
Persons Days on project Ratio
against total
days (a)
Hours as
per time
sheets
1 PB 65 0.53719 466
2 VP 121 1 848
3 BK 95 0.78512 466
3 AJ 116 0.95868 796
4 EG 77 0.63636 675
5 RL 116 0.95868 881
6 RP 52 0.42975 392
7 NG 111 0.91736 818
8 SP 111 0.91736 874
9 CT 110 0.90909 464
10 Rly 5.5 0.04545 44
11 RJ 98 0.80992 796
12 Others 41.25 0.34091 330
Total 7850
FTEs= ∑ (a) 9.24587 Misc hrs 253
Grand total 8103
Estimated effort for 121 days work
with 9.24FTEs
8944 Actual effort on
project
8103
Effort variance = (Estimated effort-
actual effort)/
Estimated effort*100
-9%
It is good to have negative effort variance which is positive indication that the team
has put less effort.
4.7.3. Integrated Project Management -IPM
Activity tracker: This is a tool which is actually used to know the flow of activities in
the project. This can also be used to check whether the project is going according to
schedule or not. This is a tool with single window for all to view. This means that
everyone who accesses it has equal privileges to view and access. Everyone in the
project has to should describe their modification or creation of new file in the product
and upload it into activity tracker. It even has automated mailing system which sends
mail to everyone in the project about any file upload
Screen shots of activity tracker:
Fig. 4.37: Screen shot: Integrated project management
Fig. 4.38: Screen shot: Creating new project plan
Fig. 4.39: Screen shot: Modifying the project plan
4.7.4. Decision Analysis and Resolution-DAR
There was cost of quality metrics done,The cost of qulity is what you spend on for
prevention of quality losses, assuring good quality and even for internal and external
failures.The cost of quality metrics is as shown below:
Table 4.15: Quality cost matrix
Sl
No.
Persons No. of
hours
Cost Type of
costs
1 PM + Project Lead for PM
activities
1056 26400 Prevention
2 QA personnel 952 23800 Appraisal
3 Testing personnel 24 600 Failure
4 Project member 36 900 Failure
Total Cost 51700
In the above metrics, prevention cost is what is spent on prevention of failures in the
planning time, the costs involved in planning the activities according to standards,
planning for following coding guidelines in software development, planning to use
good tools like version control tools. Appraisal cost is what is spent for quality
assurance, making audits reviews etc. There are two failures. The first one is internal
failure and the second one is external failure. Internal failures are the losses which
you get when you are developing your product and external failure are the losses you
get when your product is released and defects are found by customer side, so project
member has to spend his time to correct those.
If a company invests more on prevention and appraisal costs, there will be minimal
failure costs and if it doesn’t spend on these things properly, there will be more failure
costs and it will definitely cost more than what you spend for prevention and
appraisal.
The QMG of company has put the DAR guidelines in the company QMS site and
made employees easy to think about how to follow DAR and it is taking step to
educate PMs about it and to do DAR.
The screen shot shown below is the website of company that has DAR guidelines:
Fig 4.40: Screen shot: Standards and guidelines
After implementing CMMI methodology the benefits are tracked. the following are the results
CMMI methodology reduced the effort over run from 48 to 50 %before CMMI
implementation to 38 to 42 % after CMMI implementation.
Over 90% of the deliverables now made within stipulated time.
Around 10 to 12 %results in saving in the cost poor quality
4.8. Six Sigma: Improved Process sigma.
Measure phase is to examine the current state of the process, it precisely pinpoints the
area causing problems to use it as a basis of the problem-solving. Fault or defect of
the project, unit and opportunity must be clearly and precisely defined and all possible
and potential causes for such problems must be identified in this step. Subsequently
such problems are analyzed statistically, direction of the project and precise standard
of the projects subjected to the analysis must be determined.
There are mainly two jobs in measure phase. The first one is to assist define phase for
Improvement in the project selection. Before the improvement project is defined,
several Characteristics or processes shall be measured. Most of Six Sigma companies
apply the mental model (i.e. Y is a function of X). Y is selected from variation results
through Six Sigma measurement system, while X factors which influence Y need to
be identified for each Ys. The relationship is demonstrated.
The other job of the measure phase is to collect the data for the selected Ys and Xs.
Before the selection decision is made, related data such as types, sizes, measurement
intervals, and how to record the data are needed. Be different with the measurement of
process performance, measurement of Ys and Xs are more detailed and project
related.
The main activities in this phase are: identify what to measure, evaluate the
measurement system, data collection, sources of variation, and sigma level
calculation. In first activity, the current inputs, the process, and the outputs are
documented. This activity helps to measure the problem in quantitative terms.
The second activity is to evaluate the measurement system. The measurement system
is evaluated by looking at the following issues. The plan has to show works that have
to be done, added or removed tasks which are handled as the project progress, and
changes in project requirements.
The next activity is data collection in which the required data is collected. Once we
have the data, we can display it graphically. The graphical display of data helps to
find the sources of variation in the process.
The last activity of measure phase is the calculation of the sigma level.
In this phase main task is to measure the chosen process. Firstly we should make sure
what needs to be measured. Then answer the question – is our measurement system
good enough? If not, then it needs to be improved first. After that, the measurement is
started. The aim of measurement is to identify the sources of variations. At last, the
sigma level of chosen process is calculated.
The categories for the assessment criteria are Graphical User Interface, Data
Exchange, Data Processing, Data Entry, Data Interpretation, Support by Supplier,
Integration by other Methods, Utilisation, Individual Adaptability, Support For
Introduction of Software Update, Notification, Database.
The measures taken would depend on the problem at hand, and aimed at providing
indicators of how well a process delivered according to the CTQs.
Since in the define stage the problem statement was clearly defined in the measure
phase the first step is to gather data therefore, we look up the purpose of data
collection through which we can gain transparency between the customer and the ERP
software. In this stage we have to go through the software in detail and all the main
portions of the ERP software so as to reach to the conclusion of what type of data is to
be collected in order to find the purpose. To achieve the above step we take up a study
in which we ask a series of questions and doubts from an expert who is involved in
the all the major and minor processes of the ERP software. We noted down all the
details provided by the expert who explained all the modules of the ERP software and
measured the emphasis of each answer and points, which would help us to frame the
generalized questions.
The list of generalized questions which were picked up from the above session were
looked through and analyzed so as to come to a conclusion to a set of 15 questions
which would provide with the important problems that the customers are facing and
experiencing while using the software. Using the picked up the questions from the
generalized list of questions, we prepare the questionnaire of a set of quantitative as
well as qualitative questions. The quantitative questions were given a rating of a scale
from 1 to 5.Where 1 signifies the minimum satisfaction and 5 signifies the maximum
satisfaction.
The next step after the forms are received from the different department the
segregation of questionnaire is to take place. The segregation of questionnaire is done
by visual inspection and analysis. The questionnaires, which are filled by the various
customers who are the infrequent users of the ERP software, were sorted out and
separated from the customers who are the active and the frequent users of the ERP
software. The number of questionnaires collected after the segregation of the data
filled questionnaires is 158.
The rating given by the various customers to the quantitative questions which were of
the scale of 1 to 5, each of the 14 quantitative questions of each of the questionnaire
are averaged out. From the above calculation we can find the average rating of each
question and the overall rating. The overall rating that is obtained from the
questionnaire helps us figure out and structure the problem the customers are facing
while using the ERP software.
Now, the defects are to be found out. To find out the defects the sigma level technique
is used on the quantitative questions. Here the average rating of each customer was
calculated and a rating of 2 or below was assigned a defect. This is considered a
highly unsatisfactory part of the ERP software through the customer’s point of view
and is considered a defect. The quantitative question which are given a rating of 3 and
above are assigned by the customers, are considered a satisfactory part of the ERP
software through the customer’s point of view and is considered a non defect.
Fig. 4.41: Defects in each category
As the number of defects and number of non-defects or accepted questions are
calculated by going through the questionnaires, using the formula defects per million
is calculated. Defects per million is calculated as it is required and is also an important
parameter in the sigma level technique of solving problems. Defects per million is
calculated using the formula which has many factors and depends from situation to
situation. The formula is provided in the annexure.
0
20
40
60
Fig. 4.42: Six sigma calculator
The sigma level calculator is the method through which the sigma level is calculated
in this problem. In the sigma level calculator many parameters are to be filled in. the
parameters are Number of opportunities, number of CTQ’s, total number of
opportunities. After all these parameters are entered the sigma level calculator uses
these parameters and set of standard formulas to calculate the sigma level. To reach to
the final sigma level of the ERP software there are number of parameters the sigma
level calculator calculates which are, DPMO, defect percentage, yield percentage.
Now the sigma level is calculated and the value is 3.138748.
Table 4.16: Process sigma level before improvement
Number of Opportunities 158
Number of CTQs 1
Total Number of Opportunities (#Opportunities * #CTQs) 158
Number of Defects 8
DPMO 50632.91
Defect Percentage 5.063291
Yield (%) 94.93671
Process Sigma 3.238748
The weight age for each of these categories were provided by the following means:
Expert opinion
Equal weight age
Random weight age
The expert opinion weight age was given to us by the expert users of the software
from the administrative Customer of the company.
Expert weight age rating:
Here, we have made use of the weight ages provided to us by expert opinion.
Graphical User Interface – 0.08
Data Exchange – 0.08
Data Processing – 0.09
Data Entry – 0.09
Data Interpretation – 0.09
Support By Supplier – 0.09
Integration By Other Methods – 0.09
Utilisation – 0.06
Individual Adaptability – 0.06
Support For Introduction Of Software Update – 0.09
Notification – 0.09
Database – 0.09
Fig. 4.43: Weightage given by export
These weight ages given above are first multiplied by the actual ratings given by the
customers in each category to obtain the actual rating index.
Similarly, these weight ages are multiplied by the ideal rating, which is taken to be 5,
in each category to obtain the ideal rating index.
9%
8%
8%
9%
8%
11% 7%
8%
7%
10%
7%
8%
Graphical User Interface
Data Exchange
Data Processing
Data Entry
Data Interpretation
Support By Supplier
Integration By Other Methods
Utilisation
Individual Adaptability
Support For Introduction Of SoftwareUpdateNotification
Database
The actual and the ideal rating indexes are added up to obtain the satisfaction index
for actual ratings and ideal ratings. These two indexes are compared to get a fair idea
of the level of satisfaction of the customers who’re using the software.
The equal weight age was taken using the following formula:
Weight age for each category = 100 / no. of categories
= 100 / 12
= 8.83(%)
The random weight age were taken from a non-user of the software, hence random in
nature.
Equal weight age rating:
Here, we have used the equal weight age for each of the categories. The weight age
for each category is taken to be 0.083.
As done for the expert rating index calculations, each of the actual ratings in each
category are multiplied by the respective weight age in order to obtain the actual
rating index whose total sum gives the actual satisfaction index.
Similarly, the ideal ratings are multiplied by the respective weight age to find out the
ideal rating index whose total sum gives the ideal satisfaction index.
The actual and ideal satisfaction indexes are further compared to get a fair idea of the
level of satisfaction of the customers who’re using the software.
Random weight age rating:
Here, we have used the weight ages given to us by a non-user of the software such
that the weight ages are random in nature. The weight ages given to us are given
below:
Graphical User Interface – 0.09
Data Exchange – 0.08
Data Processing – 0.08
Data Entry – 0.09
Data Interpretation – 0.08
Support By Supplier – 0.10
Integration By Other Methods – 0.07
Utilisation – 0.08
Individual Adaptability – 0.06
Support For Introduction Of Software Update – 0.09
Notification – 0.09
Database – 0.09
Fig. 4.44: Random weightage
In this case too, to obtain the actual rating index, we multiply the actual ratings in
each category with the respective weight ages. The sum of the values of the actual
rating index gives us the actual satisfaction index.
The ideal rating index is obtained by multiplying the ideal rating with the respective
weight ages. The sum of this index gives us the ideal satisfaction index.
The actual and ideal satisfaction indexes help us get a fair idea of the level of
satisfaction of the end-users of the software.
Customer satisfaction index calculated:
Hence, using the weight age methods described above, we can obtain the customer
satisfaction for each of the ratings namely expert ratings, using equal weight age and
random weight age.
9%
8%
8%
9%
8%
11% 7%
8%
7%
10%
7%
8%
Graphical User Interface
Data Exchange
Data Processing
Data Entry
Data Interpretation
Support By Supplier
Integration By Other Methods
Utilisation
Individual Adaptability
Support For Introduction Of Software Update
Notification
Database
The conclusion of this calculation gives us the following data:
Expert Rating Customer Satisfaction Index = 2.96
Equal Weight age Customer Satisfaction Index = 2.98
Random Weight age Customer Satisfaction Index = 2.98
Note: Ideal Customer Satisfaction Index for each case is taken to be = 5.
We can note that the as a whole, the customer satisfaction index is nearly 60% of the
ideal. This tells us that 60% of the customers are satisfied with the usage of the
software. Also, in the measure stage, we had calculated the sigma level for the
software which is equal to 3.14. This too tells us that out of the entire Customer, about
60% of the users are satisfied with the usage of the software.
Thus we can say that the quantitative as well as the qualitative analysis of the
software are at par with each other and thus giving us a more reliable study end result.
Fig. 4.45: Average rating for categories
It is a step to improve a few key factors confirmed in the previous Analysis process
and pursue a method to improve realistic problems to be ultimately resolved. It is also
a phase to explore the solution how to change, fix and modify the process. A pilot test
00.5
11.5
22.5
33.5
4 3.61
2.76 3.27
2.31
3.44
2.785 2.84 2.81 2.53
3.16 2.78
3.11
Ave
rage
R
ati
ng
is to be made in the actual work for a month to test the improvement plans and an
analysis is to be made on the effect before and after applying the improvement plans
through statistical analysis as in the previous Analysis step. If the result is
unsatisfactory additional improvement plans must be carried out.
All of activities within improve phase are included. It starts from deciding if the
selected Y or Ys need to be improved. Then we need to identify and measure Xs
which associate with the decided Y or Ys. A group of statistical tools and experiments
are applied to find out the improvement opportunities. We can also identify the
special causes for variations among the Xs. If the result is that those variations can be
improved, then they should be removed or their impacts reduced. On the other hand,
if there are no special causes which are identified or those variations cannot be
improved, we shall reapply statistical tools and redesign experiments. If the results do
not change after several iterative, we shall consider that might be the design problems
of process or product. Then, the process or product is designed with the aim of
improvement.
Steps followed:
Gain Improvement Approval: The proposed improvement shall be approved
by everyone involved in Six Sigma project, includes all project team members,
Champion, top management, customer, related process operators. Make sure
everyone can review it.
Implement Solution: Once everything is ready, it is time to implement the
approved solution. A well-designed formal project plan will lead the whole
implementation. Make sure the defined delivers and milestones are reached on
time, and keep contact between affected groups frequently.
Gather customer feedback: If the project is customer involved, or the process
is directly affect customers, customer feedbacks shall be collected timely and
be used to modify project actions.
Assess improvement results: It does not matter that this step shall be done in
here or next phase. The improvement results will be compared with the
statement before improvement. That will show how much improvement the
project have done.
We approached few employees who had mentioned specific problems which they
were facing while using the ERP software. These problems were also found similar in
few other departments.
Since the back end process was not included in the scope of the project these
problems were analyzed and discussed with the people from the project office.
This is the last step of DMAIC cycle and as the name suggests it uses methods that
effectively help in an improvement process being deployed.
Owing to the short span of this project the control stage could not be worked on fully.
But based on the control measures certain suggestions and scope for the improvement
are given.
The objective of control module is to make sure that the problem either does
not occur or a problem that has occurred is rectified and deployed in the right
way.
Table 4.17: Problems occurred in SAP software.
Stock
Transfers
Requirement Remarks Alternative
Solution
Mfg Plant to
Depot
Stock Transfer of materials
from Mfg plant to respective
Depots:- Num ranges should
be defined for each Depot
exclusively i.e., the Num
ranges should be differnet for
each Depot, thereby resulting
in approx 30 Doc types for one
plant.
Not supported by Std
SAP, as defining
multiple doc types for a
single transaction, for
each plant is not
possible.
Depot to
Depot
For the Material moving from
Depot to Depot, the document
type should be different, so as
to differentiate the stock going
out on stock transfer between
the depots
Yes, a separate
document type shall be
defined for the stock
transfers, thereby
differentiation of the
stock transfers with the
depots and sales can be
achieved
NIL
Sales Office
[branches] to
Customers
Num Ranges for " INVOICE
" to be defined, Sales Office
Wise.
Not supported by Std
SAP.
This can be
achieved by the
help of
developing
USER EXIT
Programs.
A help file attached to the server module of the software would be of
immense help to new users and also help improve the satisfaction level of the
existing customers.
More regular surveys and feedback should be collected at scheduled intervals
of time to keep a check on the user satisfaction level.
Table 4.18: Non complying requirements in SAP software.
Issue
ID#
Module Issue Name Description Originator Status* Assigned to
Name
1 General Scope of Project Implementation of HR for Mystique
Apparels and Movers
Rao Closed Raghavan
2 SD Consignment sales material sent to Karnataka Agro-
Accounting issue to be cleared
Jayasheel /
Ramesh
Closed Kiran
3 SD Sales Pricing Structure Needs more clarity on Pricing / Discount
structure
Kiran Closed Jayasheel /
Ramesh
4 QM Core Team Member Core Team member has to be finalised. He
has to be responsible for standardising QM
process across the companies
Vinayak /
Naveen
Closed Tukaram
5 MM Material Valuation Material Valuation effects of change of
value when the value is changed in Moving
Average set up. ??
Ramesh Closed Shantaram /
Naveen
6 HR Time Management Scope of Time Management which has to
be included in the project to run Payroll
Ramesh Closed Murali to take
decision
7 MM Free Samples Inventory Valuation of the materials needs
to be zero
Ramesh Closed
8 MM Material Transfer Transfer of Valuated to non valuated
material
Ramesh Closed
9 HR Travel Management Travel management needs to be mapped
which involves the tracking of the vehicle
mileage and the spends of the employee
Vinayak /
Naveen
open Geetanjali
10 SD \
HR \ FI
Incentive Calculation Incentive calculation for the employees Vinayak /
Naveen
open Kiran /
Geetanjali
Vinayak
Issue
ID#
Module Issue Name Description Originator Status* Assigned to
Name
11 SD Invoice Numbering Stock Transfer of materials from Mfg plant
to respective Depots:- Num ranges should
be defined for each Depot exclusively i.e.,
the Num ranges should be differnet for
each Depot, thereby resulting in approx 30
Doc types for one plant.
Vinayak /
Naveen
open Kiran
12 ALL Retrospective Migration The migration is planned on a retrospective
date so that the yearly returns could be filed
properly
Vinayak /
Naveen
open Tukaram
13 SD Account Assignment issue for
Traded goods
Vinayak /
Naveen
open
14 FI Creation of asset is not possible. Narasimha open
15 FI Addition to the asset is not
possible.
Murali to take
decision
open
16 FI TDS configurations is not
complete.
Murali to take
decision
open
17 FI Service Tax provisions for GTA
(i.e. on Freight/Carriage
inward/Carriage
outward/Transportation
Charges) not configured.
Narasimha open
18 FI VAT provisions not
incorporated.
Narasimha open
19 FI Entry Tax provisions not
complied with.
Narasimha open
20 FI No financial reports are being
abstracted to our satisfaction.
Narasimha open
21 FI TDS quarterly return report in Narasimha open
Issue
ID#
Module Issue Name Description Originator Status* Assigned to
Name
the Form 26Q is not configured.
22 FI In the cash imprest account
before making entry, the system
should ask for the Company
Code. But unfortunately it will
take the previous code and
accepts the entry, which may
lead to wrong entries in the cash
book.
Narasimha open
23 FI Dunning process not explained. Narasimha open
24 FI Controlling module not
configured to our requirements.
Narasimha open
25 FI Depreciation schedule as per
Companies Act not configured.
Narasimha open
26 FI Balance sheet format under
Companies Act is not
configured.
Narasimha open
27 FI Voucher printing for various
transactions not possible.
Narasimha open
Online report generation and online integration would help access final
reports with ease and reduce time for movement of reports. Data entry-
0.690159,Data exchange-0.131803,Support-0.083428,Utilities-0.094610
Fig. 4.46: Screen Shot: User Authenticity
The software supports the variety of end user with the Authenticity.
Fig. 4.47: Screen Shot: Dynamic reporting
Dynamic report can be executed from the materials details.
Fig. 4.48: Screen Shot: Static reporting
Static report can be executed from the materials details.
Fig. 4.49: Screen Shot: Purchase order
The Purchase orders for a specific work order can be link directly into the out plant
processing feature. Purchase order is generated automatically for the selected vendor
when a work order is loaded across the shop floor for an item with an out plant
operation in its routing.
Fig. 4.50: Screen Shot: Sales order report
The sales order report can be delivery document number and delivery date from user
can be fetched form the table.
Fig. 4.51: Screen Shot: Out bound delivery
Orders can be directly transferred for outbound delivery.
Fig. 4.52: Screen Shot: Payment incoming
The details of cheque number, cheque amount, amount applied to invoice, and others
form the incoming payments can be displaced.
Fig. 4.53: Screen Shot: Billing
The billing document can generate accounting document.
Now the six sigma calculator is used to calculate the sigma level. The process
opportunities and the defects are entered into the six sigma calculator, the
characteristic to quality i.e. the unit is given as 1 because only customer satisfaction is
what we are concentrating on. The opportunities are given as 200 and the defects we
are mainly concentrating are 4 they are data entry, data exchange, support, utilities.
The sigma shift is given as 1.5
The calculated results are as follows:
The defects in percentage is equal to 2.00%
The yield in percentage is equal to 98.00%
And the process sigma is found to be 3.554.
The process sigma of the previous batch was found to be 3.15 and there 0.409
increase in the sigma level only for 4 defects. If the same is done for the other
categories of the defect then there will be an increase in the sigma level.
Table 4.19: Process sigma level after improvement
Number of opportunities 200
Number of CTQs 1
Total Number of Opportunities(#opportunities*#CTQs) 200
Number of Defects 4
DPMO 20000
Defect Percentage 2.00%
Yield 98.00%
Process Sigma 3.554
A help file attached to the server module of the software would be of immense help to
new users and also help improve the satisfaction level of the existing customers.
More regular surveys and feedback should be collected at scheduled intervals of time
to keep a check on the user satisfaction level. Creating a back-up so that manual entry
and data entry into the software need not be repeated.
Online report generation and online integration would help access final reports with
ease and reduce time for movement of reports.
Fig. 4.54 – Integrated frame work for Successful ERP Implementation
4.9 Integrated frame work for Successful ERP implementation
Integrated model aligns with the organizational operations management solution with the
business processes and information in ERP system. This model shows how the various
processes interchange information with each other as well as with the external environment.
Strategic planning activities includes provision of total quality management enabling
enterprise to implement their mission and vision by aligning policies, goals and other
stakeholders’ needs, supported by a continuously improving management of resources and
processes. The strategy is translated into plans, objectives and measurable targets. Planning
and strategy also reflects the organisation’s approach to implementing modernisation and
innovation.
Business planning activities supports enterprise in adopting new technology, follow up of
government regulations and company’s norms while the operational planning and execution
depict functionality relating to customer.
The important fact of our model is the database that should provide the integration of
information system that includes many units of measure, costing and pricing, Asset
management for materials should handle all necessary cost information like direct material
cost as well as kind of cost, form last in, weighted average or periodic value at its source.
Creation of cross system application starting from material reporting ,going all the way to
machine monitoring and control and post sales statistics, in between the critical areas
inventory issues , operational, dispatch and collection of money.
Various pricing scenarios should be provided to impact on measure the performance like
sales, profitability and customer satisfaction. For the execution of software it is necessary to
bring the notice of the end user rather than the top management. It should function like a
people driven rather than process driven. Project estimation techniques are essential to avoid
any cost or the time over run by the teams
Customer satisfaction is a closed loop that measures the satisfaction with the ERP software
they used. Potential respondents are screened prior to interviewing to guarantee inclusion of
customers of a wide range of business-to-consumer products and services, results from data
collection and analyses are released to the enterprise throughout end of each calendar year.