A

Project Report

On

“A STUDY OF QUALITY DOWNSPARK DUE TO PENDING

ORDERS IN TELECOM ORDER MANAGEMENT”

At

“KSHITIJ TECH SOLUTIONS, PUNE”

By
NAME OF THE STUDENT
Under the guidance of

NAME OF THE GUIDE

Submitted to
Savitribai Phule Pune University
In partial fulfillment of the requirement for the award of the degree of
M.B.A
Through

SHRI SHIVAJI MARATHA SOCIETY’S

INSTITUE OF MANAGEMENT AND RESEARCH

ARANYESHWAR, PARVATI,
PUNE 411009
BATCH 2022-2024

PAGE \* MERGEFORMAT 50 | Page

 DECLARATION OF STUDENT

(CERTIFICATE OF ORIGINALITY/DECLARATION)

This is to declare that I have carried out this project work myself in partial fulfillment of
the MBA Program of Savitribai Phule Pune University.

The work is original, has not been copied from anywhere else and not been submitted to
any other University/Institute for an award of any degree/diploma.

Date Signature

Place: Pune Name:

PAGE \* MERGEFORMAT 50 | Page

 DECLARATION OF GUIDE

This is to certify that the work incorporated in this Project Report

………………………………………………………………………………………………
………………………………………………………………………………………..
submitted by Name Of The Student is his original work and completed under my guidance.
Material obtained from other sources has been duly acknowledged in the Project Report.

Date: Signature Of Guide

Place: Pune

PAGE \* MERGEFORMAT 50 | Page

 ACKNOWLEDGEMENT

I would like to express my sincere thanks to the Savitribai phule Pune

University and Shri Shivaji Maratha Institute of Management And Research
for giving me the opportunity to prepare and present this report.
“There is a good saying that the work is successfully completed if the guided
properly at the right time by the right person”, with that the good
opportunities that we receive as well as the efficient supervision and the most
valuable the internal guidance.
Hereby I would like to express my deep gratitude to our project guide
“PROF.NIDHI MEDHEKAR”, who in her busy schedule provided us with full
support and encouragement, her whole hearted cooperation throughout the
progress and the completion of the project.
Last but not the least; I would like to thank our PRINCIPAL, and my friends and
other faculty for their encouragement and direct or indirect support in
completion of my project.

Name of the Student

PAGE \* MERGEFORMAT 50 | Page

 KSHITIJ TECH SOLUTION
A-1B, Pankaj Avenue,Bhosale Nagar, Behind
Amar Cottage,Hadapsar,
Pune-411028.
Email:[email protected]

Ref. No: Date:

TO WHOMSOEVER IT MAY CONCERN

This is to certify that ………………………. has completed his project work on the topic
“………………………………………………………………..” during the period from
(Tenetive 1st August 2023 to 1st October 2023)
He/She has been sincere, hardworking and punctual in his work.
We wish him success in future endeavors.

______________________
Mrs. S.P. Kanherkar
Director
Kshitij Tech Solution

PAGE \* MERGEFORMAT 50 | Page

 Table of Content
Chapter Name of the Chapter Page
Number Number
1 Executive Summary 1
a. Abstract
b. Objectives of the Study
c. Scope of Study
d. Need of the Study
e. Limitations of the Study
2 Introduction

3 Company Profile / Organizational Profile 8

4 Research Methodology 12

5 Theoretical Concepts 16

6 Data Analysis & Interpretation 22

7 Learning of Students 26
(Findings)
8 Contribution to Host Organization 27
(Suggestion / Recommendations)

9 Conclusion 28

10 References / 29

11 Annexure 30

PAGE \* MERGEFORMAT 50 | Page

 LIST OF FIGURES

Fig No. Figure Name Page No.

1.1 Importance of Recruitment 9

1.2 Methods of recruitment 11

1.3 Sources of Recruitment 14

1.4 Advantages of Recruitment 17

1.5 Limitations of Recruitment 19

1.6 Process of Recruitment 21

2.1 Organizational structure 26

3.1 Percentage of people came to know about the job 33

3.2 Percentage of employee’s satisfaction of recruitment 34

3.3 percentage of employee who preferred source of 35

recruitment
3.4 Percentage of approach of management 36

3.5 Percentage of image of the firm before getting 37

recruited
3.6 percentage of years people working in the 38
organization
3.7 percentage of rate of recruitment policy 39

3.8 Percentage of organization prefer experience 40

employee
3.9 Percentage of candidates quality 41

3.10 percentage of satisfactory method of interview 42

LIST OF TABLES
PAGE \* MERGEFORMAT 50 | Page
Table Table Name Page No.
No.

1.1 Percentage of people came to know about the job 33

1.2 Percentage of employee’s satisfaction of recruitment 34

process

1.3 percentage of employee who preferred source of 35

recruitment
1.4 Percentage of approach of management 36

1.5 Percentage of image of the firm before getting 37

recruited
1.6 percentage of years people working in the 38
organization
2.1 percentage of rate of recruitment policy 39

2.2 Percentage of organization prefer experience 40

employee
2.3 Percentage of candidates quality 41

5.10 percentage of satisfactory method of interview 42

5.11 Percentage of referred candidate 43

5.12 reliability of recruitment process 44

5.13 Percentage of correct employees 45

5.14 Declaration of internal recruitment 46

5.15 Percentage of recruitment process rate 47

5.16 Percentage of job analysis 48

PAGE \* MERGEFORMAT 50 | Page

 CHAPTER 1:

EXECUTIVE SUMMARY

PAGE \* MERGEFORMAT 50 | Page

1.1 ABSTRACT:

Here in this study I am focusing on the Telecommunication Order Management which is a

part of the entire Telecom service process. This study will highlight the study of Order
creation, Order provisioning, Billing, All Customer request related issues and servicing
functions.
The first responsibility I was assigned on this Three week of internship period was to assist
the team for the Order Management program. Secondly, I was allotted the work of creating
reports and observing the flow of orders. As an intern, I realized that I was successful to
gather a lot of significant learning experiences which would be helpful in my future career.
The IT-Operations department of VSSI offered me ample space and opportunities, not only
to learn but also to exhibit my skills as a team member. I could use my theoretical
knowledge in real practice while participating in many discussions. I was actively involved
in the department meetings where I shared my knowledge and views regarding the
performance in Operations and process automations. I also attempted to gather more
information on basic job functions of other departments to have better understanding of the
relation between them and Order management team. It was commendable to see how
wholeheartedly they welcomed, acknowledged and appreciated new ideas and knowledge.
I have provided few recommendations based upon my understanding and knowledge. I
successfully completed all the assigned duties and handed them over to the senior
supervisor at the end of the internship. I thoroughly enjoyed the challenges that came along
every single day. I could also bring some minor improvisations during my internship
which were able to leave their marks. These lessons that I have learned will be a valuable
one for my future endeavors as well.

PAGE \* MERGEFORMAT 50 | Page

1.2 RESEARCH PROBLEM DEFINITION

Vodafone shared services is a one of the giant MNCs in the market today. They support for
26 countries with over the 20k employees. Hence maintaining the quality is a crucial role
with every operating company [or client]. As there are many factors to maintain quality
one very important way is to serve end user with minimum Turnaround Time [TAT].

As discussed with the management, there were some customer’s requests kept pending at
the end of the day. This failure happens due to technological problems among the systems
involved, which is creating great impact on the business overall. Hence I selected this
subject to prepare a report on.

1.3 OBJECTIVES OF THE STUDY

 To find out the reason of delay in service:

As there are multiple processing units are involved in the system, it takes time to
process order from each system. Also there are validations on each process and every
process has its own turnaround time. Hence, need to find the reason for delay in the
system.

 To study the system which takes time to process the request:

Amongst all the processes in system, need to find most time consuming process
and find the problem in functioning of the process.

 To find out improper designs:

The coupling between two or more processes must be tightly coupled. There should
be provision to not lose the messages from the path.

 To study the improvement areas in the system:

The system needs to be updated as per the latest ideas. Hence we need to improve
the system and processes by patching it with business process changes.

PAGE \* MERGEFORMAT 50 | Page

1.4 SCOPE OF THE STUDY

I have considered the Vodafone-Greece operational company from the Vodafone

group of industries. There, we have multiple L1 and L2 service supporting from Vodafone
Shared Services of India [VSSI]. Also we have limited services supported from here, such
as CRM, Pending Orders, Fix Assets Provisioning [FAP], Middleware [OSB & ESB],
Business Analytics, Provisioning etc. I have only included the important services as CRM,
Pending Orders, Middleware [OSB].

1.5 NEED OF THE STUDY

VSSI is already running its services at very good quality and provide innovative
solutions to make system error free and more productive. But though processing systems
are good and handles multiple orders at a time, they are prone to errors and are not capable
to handle few errors. Hence there is need to uplift logic with some alternative
programmatic work which will take actions as per the logic written in the file. Daily
multiple requests come to the system and system resolves them with the base of pre-
existing logic in the system. As long as request is agreeable with the logic, system will
accept it and take actions accordingly. But if request is not raised properly or there is some
other system issue to accept the case, then it will get stuck in the system. This causes the
delay in fulfilling the request of the customer. Example, if customer requested data plan of
some amount and though after giving the money. Data bundles are not getting activated to
the customer.

PAGE \* MERGEFORMAT 50 | Page

 1.6 LIMITATIONS OF THE STUDY

On-site dependency

Uneven inflow Limitations on Access

LIMITATIONS

Technical barriers Complex Process Designs

Knowledge Gap

PAGE \* MERGEFORMAT 50 | Page

 CHAPTER 2:

INTRODUCTION

PAGE \* MERGEFORMAT 50 | Page

 2.1 INTRODUCTION

Now-a-days telecom has spread its effect on global level. There are lots of services
provided by telecom operators like Vodafone, Airtel, Telenor, British Telecom etc. Main
services are as follows:

1. Calling
2. Text Messaging [SMS]
3. GPRS [General Packet Radio Service]
4. IP TV
5. Broadband

Other than these services are extra add-ons to the services. Such as call diverts, caller
tune, 3G/4G Services, any additional packs etc. in this study I am only focusing on Mobile
services offered by Vodafone Greece. All studies and details are focused to VFGR
environment.

There are two important aspects in the telecom industry such as Operation Support
System [OSS] and Business Support System [BSS].

2.2 OPERATION SUPPORT SYSTEM (OSS):

Operations support system (OSS) is a software component that enables a service

provider to monitor, control, analyze, and manage the services on its network. These types
of software applications, along with a business support system (BSS), support most
customer-facing activities, including ordering, billing, and support.

The development and implementation of OSS systems often involve information

technology (IT) expertise as well as the help of integrators that can ensure the software
works with network infrastructure to pass on important information about the fulfillment
and delivery of services.

2.3 BUSINESS SUPPORT SYSTEM (BSS):

Platforms used by service providers, telecom operator delivery product

management, customer management, revenue management (billing) and order

PAGE \* MERGEFORMAT 50 | Page

management applications that help them run their business operations. BSS platforms are
often linked to OSS platforms to support the overall delivery of services to customers.

Primary BSS areas are as follows:

1. Product management
2. Customer management
3. Revenue management
4. Fulfillment management

2.4 OSS AND BSS INTEGRATION:

OSSs emerged in the traditional voice telephone systems as a way to manage voice
connections. They were later adapted to manage IP-based Internet traffic (including VoIP)
and broadband services. Together with the BSS, the OSS is important for delivering many
business functions. The two systems are often tightly linked and sometimes referred to
together as OSS/BSS. An OSS can transmit order, fault, and service assurance information
to the BSS.

The OSS/BSS market is huge, estimated by various research firms to approach $50
billion worldwide. Some of the key players in the OSS market are Amdocs, Ericsson, HPE,
and Oracle.

Both OSS and BSS software can require heavy development to launch new services. While
they are often used by network architects and engineers to monitor and maintain systems,
they are typically developed and maintained by IT staff, which in many telecom operators
is distinct from the network architecture staff.

PAGE \* MERGEFORMAT 50 | Page

 CHAPTER 3:
COMPANY PROFILE/
ORGANISATION PROFILE

PAGE \* MERGEFORMAT 50 | Page

3.1 INTRODUCTION TO ORGANIZATION

Kshitij Tech Solutions is a manpower solution enterprise which delivers Skilled resource
for various Multinational Companies. It has matured over the past 3 years, delivering value
to its partners and significantly contributing to customer experience.

Established in 2016, Kshitij Tech has evolved from being a single entity into a multi-
functional organization which currently covers Pune, Mumbai and Nashik with over 200
professionals.

In last year, Kshitij Tech has transformed its approach from being a reliable service
provider to becoming a strategic partner with a focus on value and business outcomes, and
become a key lever for different organizations to drive cost saving, skilled and quality
resource programs across in Markets.

They're doing this by effectively enabling the trending strategy and playing a key role in
delivering skill-bridge, innovation and higher levels of profitability.

From Pune-Mumbai-Nashik to entire India, they all working together to produce the best
solutions and the most rewarding results. Great minds think alike here at Kshitij Tech.
Enriching lives is not just something we do for our customers; sharing what best it there in
the market is what we offer.

PAGE \* MERGEFORMAT 50 | Page

3.2 VISION OF THE KSHITIJ TECH:

Lead the change for Kshitij Tech as a strategic partner, to create a competitive edge and
improve profitability

Kshitij Tech Value Drivers

a. Maximize Cost Arbitrage: Continue to optimize footprint, increase Kshitij Tech

penetration and expand its P&S portfolio.

b. Enhance Productivity: Do it better & smarter through leveraging business excellence

and automation technologies.

c. Capitalize Knowledge: Leverage Kshitij Techs’ diverse experience and

telecommunications know-how to deliver innovative business solutions and services that
identify new opportunities.

3.3 PORTFOLIO OF SERVICES

Today, Kshitij Tech takes pride in owning a wide portfolio of services, supporting
Local Markets. This covers various capabilities including: Finance, Supply Chain,
Customer Operations, Sales and Marketing, Product Development and Management,
Legal, Fraud, Credit and Collection, HR, Technology, Networks and Business Intelligence.

PAGE \* MERGEFORMAT 50 | Page

3.4 ORGANIZATION STRUCTURE:

CEO

Administration Accounts and Finances

Resourcing Marketing Sales

We have two main departments directly reporting to CEO, Administration and Accounts &
Finances. Where Administration Team further delivers the Resourcing and Marketing
functions. And Accounts & Finances Department tightly coupled with Sales functions as
well.

3.5 SWOT ANALYSIS:

PAGE \* MERGEFORMAT 50 | Page

Strengths: Weaknesses:
- Massive market coverage
- Dropping subscriber base
- Revenues generated
- Dropping brand valuation
- Marketing
- Losing market share due to time
- Premium cost
lapse
- Subscriber base
- Poor performance in long-term
- Brand recall and brand valuation
contracts

Opportunities: Threats:

- Emerging markets - Competition

- Dependency on Organization’s - Low margins
requirement. - Saturation
- Improving the network

PAGE \* MERGEFORMAT 50 | Page

 CHAPTER 4:

RESEARCH METHODOLOGY

PAGE \* MERGEFORMAT 50 | Page

4.1 RESEARCH:

Research can be defined as the scientific search for knowledge, or as any systematic
investigation, to establish novel facts, solve new or existing problems, prove new ideas, or
develop new theories, usually using a scientific method.

4.2 RESEARCH METHODOLOGY:

Research methodology is a way to systematically solve the research problem. It may be

understood as a science of studying how research is done scientifically. In it we study the
various steps that are generally adopted by a researcher in studying his research problem
along with the logic behind them to give a solution for the problem by collecting data,
analyzing data & find the conclusion for the problem.

The system of collecting data for research projects is known as research methodology. The
data may be collected for either theoretical or practical research for example management
research may be strategically conceptualized along with operational planning methods and
change management.

4.3 TYPE OF RESEARCH USED:

Exploratory Research:

Here in this approach, I have used Exploratory Research technique to get better
understanding of a problem. There are multiple orders failed or stuck in the system due to
some problem in the submission activity and/or handling method of the involved
processes. There are multiple techniques used to study the problem in the system such as:

- Literature Survey
- Experience survey
- Depth interview

PAGE \* MERGEFORMAT 50 | Page

Experimental Research:

Under this study, I have found the cause of failed orders and the effect of them on the
adjacent processes. There are weekly changes and upgrades done on different processes
but other systems do not changed accordingly, hence the request gets unprocessed from the
respective systems. Like said before, there are other causes also which results into failure
as an effect of the change.

4.4 SAMPLING:

Sampling is the process of taking random number of observations from a larger population.
As we cannot study the entire population, it takes the proper amount of portion out of the
entire population. Likewise I have studied only for two month’s data.

VSSI has serving many Vodafone OpCos such as Greece, Italy, UK, and Qatar in many
operational areas. So I have selected sample only for Greece, CRM, GSM Pending order
Management as I was focusing on the entire Order processing and the internal structure of
service model.

Sampling Size:

The sample size will be the total number of [GSM] failed/ pending order’s count for the
months of June and July 2019. They were failing at different stages or processes in the
system.
In Pending Order’s team we had ~2000 orders collectively in the month of June and July.
Which further classified into different failed categories. As we have Customer base of the
country is almost 4.5 million, failed order count number becomes small [0.04%] but still
that means 2k customers are having trouble while using the service.

PAGE \* MERGEFORMAT 50 | Page

Sampling Method:

Non-Probabilistic or Judgement sampling was adopted for the study. The survey was
conducted on the basis of Convenience sampling method. That is, as per the convenience
of the team, management researcher fixed the sample size.

4.5 Data Collection Method:

I have collected data in both Qualitative and Quantitative methods implementing the
processes in the system. In the study, I have added opinions from team members and also
checked the daily failed order’s lists taken out from the system. Also added to it, I have
checked the Weekly dashboard and EODs to make sure the count is true and flexible as per
the system’s performance.

Primary data

Primary data is the new or fresh data collected from the personal observations and also
taken personal interviews of the team members. I have collected all the data by personally
observing the day-to-day work [BAU]. Also gets the knowledge from employees working
in the team.

Secondary data

The secondary data are collected through the internet and Standard Operating Procedures
[SOPs]. Also few data patterns are referenced from Company database.

Data analysis techniques to be used:

The data was summarized in the Microsoft Excel sheets for Tabulation and Bar charts.
Also used it for reporting purpose for the higher management. To find out the pattern I
have used Microsoft Excel to get the view of the pending orders from sample.

PAGE \* MERGEFORMAT 50 | Page

4.6 Research Instrument:

I have used Observation method to research the information regarding the subject.
Within that, I have observed the actions taken by the respective team members. Actions
include correcting the order as per the standards and resubmitting the same order into the
system. Also sometimes team asks for the information from Shops and source teams to fill
it into the order and push it again into system.

Variables:

Incoming orders are the dependent variable in the whole process. These are the
customer requests in a structured format so as to push it to all the back end systems such as
provisioning, Billing etc. all other systems will become dependent variables on the order’s
inflow from different sources e.g. Call centers, VOP, System Retention etc.

As there are different sources of inflow of orders, each input point of the order is
independent variable and other systems are dependent on the order creator system.

PAGE \* MERGEFORMAT 50 | Page

 CHAPTER 5:

THEORETICAL CONCEPTS

PAGE \* MERGEFORMAT 50 | Page

5.1 Typical Telecom Business Process:

As figure explains the phases of Typical Telecom Business Process, Order management
lies at step 4,5,7,8. Order Management is vital part of telecom business process. As it
directly deals with the customer service, it creates a major impact on customers and the
quality of a service.

PAGE \* MERGEFORMAT 50 | Page

5.2 Service Fulfillment Process: OSS

The "fulfillment" process embodies a range of OSSs – including:

 Order management
 Inventory
 Provisioning
 Service activation

5.3 Order Management:

The order management and provisioning processes is the key OSSs involved in
configuring the network to deliver the service desired by the customer (i.e., fulfillment).
The aim of an order management system (OMS) is to order the service the customer
requests, support changes when necessary, keep the customer informed with meaningful
progress of their order, and track and manage to successful and on-time completion.
The process begins with an order or, in some cases, pre-sale activity. The process ends
with a completed order, a delighted customer and sufficient information to build or update
a customer account record in trouble/problem handling, performance reporting and billing
processes and systems.

5.4 Benefits of Order Management :

1. Time-to-market for new services is minimized
2. Failed orders is reduced to zero
3. Time to deliver services is minimized
4. Labor-intensive manual processes are eliminated
5. Reliable service to customers

PAGE \* MERGEFORMAT 50 | Page

Features of Order Management :
 Accepting orders
 Pre-order activity
 Integration with Inventory database
 Integration with SLA to know whether the customer is eligible for the service ordered
and also to estimate the price for the service.
 Reserve available facilities to support the order.
 Initiate service installation
 Notifying the customer
 Initiate billing process
 Order plan development
 Request customer deposit
 Issue order and tracking order status
 Integration with workflow management system to dispatch a technician to install a
service
 Web ordering
 Data-driven Architecture
 API Support
 Workflow engine
 Notification for new ticket assignments or escalations to appropriate personnel,
individuals or teams
 Multi Platform Support
 Quote service price
 Payment engine
 Integration with CRM

PAGE \* MERGEFORMAT 50 | Page

5.5 Core Business processes in Order Management:
 Accepting orders
 Pre-order activity and Credit Check
 Price estimates
 Order plan development
 Request customer deposit
 Reserve number
 Initiate service installation
 Notifying the customer
 Initiate billing process

5.6 Order Manager:

The order manager coordinates all aspects and processes related to fulfilling an
order - including validation, service decomposition, inventory update, provisioning, billing
and testing

5.7 Provisioning Process:

The provisioning OSS works with the order manager to activate the service within
the corresponding network element(s).The provisioning OSS also handles configuring the
network for dynamically-oriented transactions — such as authentication, accounting,
authorization, roaming, etc.

5.8 Service Fulfillment flow:

Sales process caters for the customer queries, for the various available services.
Customer places the service order directly to the order management system or through
sales process.
Order management process hands over this order to Service Configuration process
to activate the service. Customer related details are saved in the OMS, which can be used
by the assurance and billing processes. Service Configuration system assigns this service
request to Network Provisioning System , that in turn sends this request to its sub-process

PAGE \* MERGEFORMAT 50 | Page

“Network Configuration and Routing” to actually configure the service at Network
Element Level.
Network Configuration and Routing system checks the validity and availability of the
network data through Network Inventory Management sub-process and then configures the
service on Network Element Management and network elements.
After configuration of Service, Security sub-process checks for the network access on the
configured elements.

Network Configuration and Routing sub-process requests the Test Management sub-
process to check the configured service. This test sub-process checks whether configured
service is working or not. Test completion results are sent back to the Network
Configuration and Routing sub-process.

Network Configuration and routing sub-process sends the network completion status to the
Network Provisioning process. If the Service is successfully configured, Network
Inventory Management sub-process is updated with data used for assigning the service.
Network provisioning system updates the Service Configuration process after assignment
of service is completed.

Service Provisioning process informs the Order Management about the result of Service
Request. It also updates billing system to start the billing for the given customer.
Sales process or Order Management system informs the Customer about the activation of
service it has asked for.

PAGE \* MERGEFORMAT 50 | Page

5.8 SYSTEM ARCHITECTURE:

As shown in fig. there are multiple systems involved in the process to fulfil the Customer’s
request.

PAGE \* MERGEFORMAT 50 | Page

Sources:

These are the sources through which system accepts the customer request. There
are multiple sources such as mobile application (iPhone/Android), online portals, customer
care centers, SMS, Interactive Voice Records [IVRs] etc.

Customer Relationship Management tool [CRM]:

This is the system which converts the customer’s request into system
understandable format such as order or ticket. It also reflects the current status of the order
in number of different systems.

Analytics:

This system analyses the entire process from business point of view. It records the
inflow and outflow of the requests from/to the system. It has already maintained business
related functions and pre-decided actions to take on data. Such as comparing the current
data with last month’s data, past 6 month’s data and year’s data etc.

Shops:

These are the outlets of the services and products. As per the customer’s request it
initiates the sale or marketing of the new products etc. It also initiates different campaigns
to attract new customers to use the service.

Middleware:

Middleware acts as a translator in the system. It accepts the request from CRM,
decomposes it and then transfers it to different third-party systems to process it from their
end.

Third party systems:

These are the mediation systems, involves Provisioning systems and Billing and
Retail Management systems.

PAGE \* MERGEFORMAT 50 | Page

5.8 TERMINOLOGIES:

Order:

Each request from customer is converted into an order for processing through the
system. It is the summary of customer’s current services and products used, and customer’s
new request or modifications to the service. It contains Main Line Item [MLI] and Line
items [LI].

Oracle Service Bus [OSB]:

This is the oracle’s product from fusion middleware. Weblogic is the main product
which mainly used here. It holds all Business services and Proxy services to connect
internally and to the external systems respectively.

Service Oriented Architecture [SOA]:

SOA mainly decomposes the entire order structure into downstream systems to
make changes from their end and then lastly it sends combined response to CRM.

Billing and Retail Management [BRM]:

We have oracle stack to maintain billing related information. Every Pospay

customer receives billing at the end of its billing cycle. VFGR has 19 billing a cycle on
which billing gets generated of different customers.

Basics of Siebel Order Management:

Siebel offers powerful order management capabilities. You will explore the real depth of
orders largely in the telecom and media vertical, where there is a lot of CPQ (Configure,
price, quote) play. Application programming interfaces (APIs) are at the heart Siebel

PAGE \* MERGEFORMAT 50 | Page

eConfigurator and were exposed for developers in Siebel 7.5. But they weren’t really
noticed till Siebel 7.8.

Although APIs are largely relegated to the background with what can be achieved in Siebel
8.0 higher level business services and web services for product configuration, it doesn’t
hurt to know them better.

Siebel order management offers one of the most powerful functionality for end-to-end
order processing within the CRM framework. This not only includes creation of orders ,
but also customising order line-item ( contents of the order ), validating orders , pricing
them, and tracking them through fulfilment. Of course the same functionality is also
enabled on quotes, and you can process orders/quotes for accounts or contacts.

Asset based ordering (ABO) enhances the order management functionality by enabling a
greater level of interaction between quotes, orders, and assets.

A lot of order management is driven by Siebel business services and workflows in the
backend. eConfigurator UI provides an new dimension to order management by hiding
complexities behind a user-friendly interface. Of course this user-friendliness has been
increased multifold in the all-new Open UI eConfigurator. The UI provides an easy way to
configure/customise products for an order or a quote.
eConfigurator uses APIs in the backend.

PAGE \* MERGEFORMAT 50 | Page

How Does An Order Get Processed?

The order life-cycle in Siebel deals with three main entities – quotes, orders, and assets.
ABO connects all three to establish the entire process – While quotes and orders represent
the pre-fulfilment part, assets are considered as the core entity post fulfilment.
A deal/ potential deal with the customer gets initiated through an opportunity, or through a
quote. A quote is transformed into an order at the click of a button once the terms of the

agreement are acceptable to the customer. An order (order line item to be specific)
transforms into the asset through the “auto asset” functionality. This is where you click a
button and the entire details of the order and line items find their way to the asset.
Quote or an order can have a mix of simple products, or complex products. Complex
products can have components of their own, and are also known as customizable products.
While you can directly create complex products against an order/quote, eConfigurator is
Pricing rules are also applied within the configurator. Changes to the customizable product
are reflected in real-time, politicians/error messages are carried out with every click, and
pricing changes are displayed on the UI.
The above said rules as well as pricing are applied outside the eConfigurator as well. He
just makes it harder to search and create line items against individual products, rather than
look at an eligible list of products to pick and choose.

PAGE \* MERGEFORMAT 50 | Page

ORDER LINE ITEM STATUS:

Diagram above shows the Order Line item status when the order is been created from
CRM.

PAGE \* MERGEFORMAT 50 | Page

Pending Submission:

Whenever user tries to create order, it remains in NEW status and order line items
will be in PENDING SUBMISSION. In this status user can be able to make changes on
Line items manually. S/he can be able to change the action code and fill the required
details into the order.

Not Active:

After submitting the order, all Line items will turn into NOT ACTIVE state. In this
state all changes gets fixed into the order and order will be pushed into the CRM Queue.
CRM will create one xml and send it to OSB to process further.

Viper Queue:

The first process is provisioning path to be followed in the system. Hence CRM
system will be make Line Item’s status to VIPER QUEUE. Then it will be transfer to
Viper system for provisioning the services required.

Viper Failure:

When Line item fails in a Viper system due to some reason, then the Line item
status changes to VIPER FAILURE. It reflects the error description to the CRM.

Provisioning Complete:

When everything goes right in Viper system then all line items goes to
PROVISIONING COMPLETE status. Order gets hold here and in the back end CRM will
send request to BRM to either check the Billing Account number in the system or add new

PAGE \* MERGEFORMAT 50 | Page

one in New Connection case. If everything goes right, order will pushed to Connection
path.

Connection Queue:

After provisioning part, all line items will move to Connection part. Here in this
path line items will be transfer to BRM and ALU systems.

Connection Failure:

If some Line item fails on some of the Connection path system, then Line Item’s
status changes to CONNECTION FAILURE. It comes back with an error on CRM.

Connected Item:

If everything goes right, then Line Item will be connected and order will get
completed. After completing the request it will be reflected in customer’s connection.

PAGE \* MERGEFORMAT 50 | Page

 CHAPTER 6:

DATA ANALYSIS AND

INTERPRETATION

PAGE \* MERGEFORMAT 50 | Page

In this chapter we are analyzing data on three categories:

1. Daily list report

2. End Of the Day dashboard
3. Weekly Dashboard

Daily list report is the collection of all failed orders with affected MLI and LI. It also
contains stuck line items in the OSB state. There are some line items stuck in queues where
OSB side action requires. So this report will give you total summary of failed or stuck
orders in the system. This report is prepared for internal use. It contains scope till Manager.

End of the Day Dashboard gets prepared every end of the day. It contains every
order processed in the day. It is a summarize version of all four Daily list reports fetched
from system. While making charts it has four different parts such as total status wise order
count, stuck order count and processed order count, third party dependent orders, stuck line
item count of the orders. This report goes to higher management and Analysis team to save
it for future reference purpose.

Weekly dashboard is a table prepared for internal use. It summarizes the total
processed orders, inflow of orders, and pending order’s count. This report is also goes to
the higher management and data analysis team. It is the summary of all orders processed
from daily list reports; orders came through tickets, New Connection order etc. It contains
all inflows and different SLA wise orders processed from all inflows.

PAGE \* MERGEFORMAT 50 | Page

 6.1DAILY LIST REPORT:
Pending Orders team pulls orders from the system 4 times a day. The report
consists of the affected Order with Line Items and their status, MSISDN, Order status,
Error Description, Failed system etc. Majorly all data divided into two categories affected
Main Line Item [MLI] or affected Line item [LI], and their status wise count as below.
For MLI:
Row Labels Count
Connection Failure 8
Not Active 1
Provisioning Complete 69
Viper Failure 32
Viper Queue 30
Connection Queue 59
Grand Total 199
Table: 6.1
Table 6.1 shows status wise count of Main Line Item. It summarizes the total stuck count
of MLI and presented as table shown.
Interpretation:
Fig.6.1 is the pictorial representation of table 6.1. It depicts the total count and
major failure area in the system and needs to focus. This is the best way to get a complete
picture of a system in a glance.

Failed Line Item count

Viper Queue 30
Viper Failure 32
Provisioning Complete 69
Not Active 1
Connection Queue 59
Connection Failure 8
0 10 20 30 40 50 60 70 80
Fig.6.1

PAGE \* MERGEFORMAT 50 | Page

For LI:
Row Labels Count
Connection Failure
Connected Item 370
Connection Failure 240
Connection Queue 10
120

Connection Queue 115

Connected Item 80
Connection Failure 2
Connection Queue 33

Not Active 5
Connected Item 1
Not Active 3
Viper Failure 1
Provisioning Complete
Provisioning Complete 1391
Viper Failure 799
Viper Queue 155
Connection Queue 86
351

Viper Failure 87
Connected Item 29
Provisioning Complete 1
Viper Failure 51
Viper Queue 6

Viper Queue 875

Connected Item 92
Provisioning Complete 69
Viper Failure 5
Viper Queue 709
Grand Total 2843
Table 6.2

Interpretation:

Table 6.2 is the summary of affected Line items in given data. We receive one zip file
with all affected orders and line items. This table shows that total stuck line item count
stuck as per the failed state. In order there is only one Main Line Item and multiple Line
Items, hence Line Item count will always be greater than MLI count.

PAGE \* MERGEFORMAT 50 | Page

6.3END OF THE DAY DASHBOARD:

This is the report, which collectively shows how many orders are processed by the team in
whole day, and how many are pending on other team’s actions. Pending order’s status,
their failed systems, Line items status and order type wise pending summary.

 Order inflow and processed status:

Inflow Processed Pending

Order Type
Orders Orders Orders
Bar/Unbar 225 225 0
Change MSISDN 351 349 2
Change MyZone 65 65 0
Change SIM 26 26 0
Change Tariff 354 334 20
Disconnection 450 448 2
EC 2 Postpay 24 24 0
EC 2 Prepay 29 29 0
Ex Prepay 21 21 0
General Modify Order 15 15 0
Modify VPN 45 45 0
New Connection 13 10 3
New EC 23 23 0
New Prepay 550 548 2
One-Off 200 198 2
Port In Postpay 8 7 1
Port Out 34 32 2
Postpay to Prepay 13 13 0
Reconnect 3 3 0
Renewal 54 54 0
Tranfer 10 10 0
Table: 5.3

Interpretation:

As shown in the table 5.3, there are total inflow orders processed orders and total
pending orders due to other system dependency. These are the total number of orders
received by Pending Order’s team. This count is calculated by adding four daily reports
from the system.

PAGE \* MERGEFORMAT 50 | Page

 600
400
200
0
Inflow Orders
Processed Orders
Pending Orders

Fig 5.3

 Pending order count on third party systems:

Third party system Count

ALU 3
BRM 8
ENT 2
NETWORK 1
SHOPS 3
USER 17
Table 5.4

ALU – Alca Lucent Provisioning CVC – Connections Group BRM – Billing and Retail Management

Interpretation:
These are the failed orders on different third party system’s pending for an action.
After taking actions from their side, Pending orders team may proceed to take actions from
their end.

Pending Orders
18
16
14
12
10
8
6
4
2
0
ALU BRM ENT NETWORK SHOPS USER

Fig6.4

PAGE \* MERGEFORMAT 50 | Page

 Line Item Status:

Count(*
LI Status )
Provisioning
Complete 54
Viper Queue 3
Viper Failure 39
Connection Queue 4
Connection Failure 30
Cancelled Item 10
Table 6.5
Interpretation:
Table 6.5 shows Pending Line Item’s count. This is the Pending Line item count
stuck in the system due to any reason. Mentioned are the statuses through which order gets
complete. This count includes failures and other dependent Line Items in the system.

LI Status
60

50

40

30

20

10

0
Provisioning Viper Queue Viper Failure Connection Connection Cancelled Item
Complete Queue Failure

Fig 6.5

PAGE \* MERGEFORMAT 50 | Page

 Total Order Wise status:

Order Status 2513

Completed 2470
Incomplete 32
Cancelled 9
Submitted 2
Table 6.6
Interpretation:
Table 6.6 shows status wise order count which gives us the top view on the system
and status of pending count. It has the summary of all status wise failed and stuck orders.

9
32 2

Completed
Incomplete
Cancelled
Submitted

2470

Fig 6.6

PAGE \* MERGEFORMAT 50 | Page

7 WEEKLY DASHBOARD

Week 1
Wednesda
y
Connected LI 24
VIP tickets, Bundle Bucket Issue 35
UBA Issue 20
Orders Stuck in Validation Failure 15
New Connection 50
One-Off, Modify Ebill, New Billing Account
Creation 800
GSM
Orders
Total Orders 6719
Progressed Orders 6677
Incomplete Orders 42
Table 6.7

The table shows the weekly resolved orders and other issues from different sources. Here
Oracle Siebel CRM is used as a ticketing tool to resolve requests.

800
600
400
200
0
LI ue ue r e on on
cte
d Iss Iss ilu cti ati
e t A Fa e r e
nn ck
e
UB n nn tC
Co Bu atio Co un
le lid w co
nd Va Ne Ac
Bu n g
s, ki llin
ket tuc Bi
tic r sS ew
VI
P de lil , N
Or Eb
ify
od
ff ,M
e-O
On

Fig. 6.7
PAGE \* MERGEFORMAT 50 | Page
 CHAPTER 7:
FINDINGS OF THE STUDY

PAGE \* MERGEFORMAT 50 | Page

KEY FINDINGS:

1. There are orders stuck in a system due to wrong data acceptance from CRM like
extra special character in a field or wrong offer name etc. These mistakes results
into failure on other systems.
2. Orders get stuck due to submitting wrong orders into the system for wrong request.
Such as, for adding an offer, Customer care representative raises change tariff
order, which has entirely different functionality.
3. Orders stuck due to system validations such as character length for different
systems varies as per their processing and system asynchronous alignment.
4. Some orders stuck due to middleware incompatibility to communicate with other
systems. As middleware is used the OSB which is Oracle’s product and other
systems are not from the Oracle’s suite. Hence compatibility should be manually
configured to tightly couple to each other.
5. Unmanaged inflow of orders. There is not scheduling system implemented at the
receiving end to manage the flow of orders.
6. There are no read accesses on of some of the processes. While taking actions from
CRM we need to make sure that the updated status of the MSISDN at different
processes. In current scenario we do not have access to check it by ourselves.
7. There is one screen named “No-Rules screen” which does not have any validations
on it and by using that screen CSR agents raising an order, which fails due to
wrong order creation.
8. As due to security issue, we cannot run tools from local machine, it is very difficult
to process on orders with slow speed.
9. Less automation implemented.

PAGE \* MERGEFORMAT 50 | Page

CHAPTER 7:
SUGGESTIONS

PAGE \* MERGEFORMAT 50 | Page

As per above observations there are multiple situations through which orders may stuck in
the system. But we can resolve it through applying multiple solutions on multiple
situations.
1. There is a need to revise data validations on order creation sources. Such as order
can be raised from App or portal with minimum inputs to system and other values
are configured in CRM.
2. Customer care executives need to be educated regarding order structure and
creation process.
3. There should be all backend validations to be applied on facing system such as
CRM.
4. While upgrading, patching, new deployments and releases we should consider the
effect of upgradation on other systems as well.
5. We have different sources of orders and we do not have any control on inflow of
the system. Whenever there are large number of bulk orders may get submitted,
managing the flow will result in system running in a smooth manner.
6. As the structure is very complicated, sometimes order will get completed without
going to some processes. Hence next time whenever order raise to change the
existing offer, the latest order fails. This results in raise in pending order count.
Need to simplify the architecture.
7. Need to manage the work amongst team. Current method is time consuming and
prone to dependencies as well as current approach is to resolve the order and not
problem.
8. There are different SLAs to different inflows of problems. Hence PO team has
multiple sources as well for checking the issues in systems.
9. Need to implement different scripts on servers and Remote Desktops to take
actions on bulk failed orders in one go.

PAGE \* MERGEFORMAT 50 | Page

CHAPTER 9:
CONCLUSION

PAGE \* MERGEFORMAT 50 | Page

There are different systems involved into the complete process. Every system works
independently and in an isolate manner. Every order comes with some request, whether it
may be for modification, new, renew or deletion. There are multiple order types involved
in this process, as per the customer’s requests. Every order type has some mandatory fields
at different internal systems. Hence every validation on internal systems should be applied
on face system [CRM]. All systems should be in sync with each other.

Also system must guide the end user and while applying such validations we should
consider that user may not be technical sound and s\he may or may not familiar with the
implemented process, hence multiple validations should be applicable to the face of the
application.

Entire order flow contains multiple sub processes hence these sub-processes are
interdependent on each other to fulfill the customer request. So as to make process efficient
and pro-active, we need to maintain compatibility and synchronization among all the
processes.

PAGE \* MERGEFORMAT 50 | Page

CHAPTER 9:

REFERENCES

PAGE \* MERGEFORMAT 50 | Page

Paraskevi G., (2013), Standard Operating Procedure (SOP), Vodafone shared services
India Company operations document. 10-115.

Vrtanoski, Jordan (2011), Order management system,

https://en.wikipedia.org/wiki/Order_management_system

Dani Hao,All You Need to Know About Order Management And How to Speed Up Your
Procurement Timeline, procurify blogger site.

https://blog.procurify.com/2018/03/13/need-know-order-management-speed-procurement-timeline/

Prashanth Krishnamurthy, Basics of Siebel Order Management and eConfigurator, crmcog

Blog.
https://crmcog.com/basics-of-siebel-order-management-and-econfigurator/

ORDER LINE ITEM STATUS:

PAGE \* MERGEFORMAT 50 | Page

Diagram above shows the Order Line item status when the order is been created from
CRM.

Pending Submission:

Whenever user tries to create order, it remains in NEW status and order line items
will be in PENDING SUBMISSION. In this status user can be able to make changes on

PAGE \* MERGEFORMAT 50 | Page

Line items manually. S/he can be able to change the action code and fill the required
details into the order.

Not Active:

After submitting the order, all Line items will turn into NOT ACTIVE state. In this
state all changes gets fixed into the order and order will be pushed into the CRM Queue.
CRM will create one xml and send it to OSB to process further.

Viper Queue:

The first process is provisioning path to be followed in the system. Hence CRM
system will be make Line Item’s status to VIPER QUEUE. Then it will be transfer to
Viper system for provisioning the services required.

Viper Failure:

When Line item fails in a Viper system due to some reason, then the Line item
status changes to VIPER FAILURE. It reflects the error description to the CRM.

Provisioning Complete:

When everything goes right in Viper system then all line items goes to
PROVISIONING COMPLETE status. Order gets hold here and in the back end CRM will
send request to BRM to either check the Billing Account number in the system or add new
one in New Connection case. If everything goes right, order will pushed to Connection
path.

Connection Queue:

After provisioning part, all line items will move to Connection part. Here in this
path line items will be transfer to BRM and ALU systems.
PAGE \* MERGEFORMAT 50 | Page
Connection Failure:

If some Line item fails on some of the Connection path system, then Line Item’s
status changes to CONNECTION FAILURE. It comes back with an error on CRM.

Connected Item:

If everything goes right, then Line Item will be connected and order will get
completed. After completing the request it will be reflected in customer’s connection.

PAGE \* MERGEFORMAT 50 | Page

 CHAPTER 5:

DATA ANALYSIS AND

INTERPRETATION

PAGE \* MERGEFORMAT 50 | Page

In this chapter we are analyzing data on three categories:

4. Daily list report

5. End Of the Day dashboard
6. Weekly Dashboard

Daily list report is the collection of all failed orders with affected MLI and LI. It also
contains stuck line items in the OSB state. There are some line items stuck in queues where
OSB side action requires. So this report will give you total summary of failed or stuck
orders in the system. This report is prepared for internal use. It contains scope till Manager.

End of the Day Dashboard gets prepared every end of the day. It contains every
order processed in the day. It is a summarize version of all four Daily list reports fetched
from system. While making charts it has four different parts such as total status wise order
count, stuck order count and processed order count, third party dependent orders, stuck line
item count of the orders. This report goes to higher management and Analysis team to save
it for future reference purpose.

Weekly dashboard is a table prepared for internal use. It summarizes the total
processed orders, inflow of orders, and pending order’s count. This report is also goes to
the higher management and data analysis team. It is the summary of all orders processed
from daily list reports; orders came through tickets, New Connection order etc. It contains
all inflows and different SLA wise orders processed from all inflows.

PAGE \* MERGEFORMAT 50 | Page

8 DAILY LIST REPORT:
Pending Orders team pulls orders from the system 4 times a day. The report
consists of the affected Order with Line Items and their status, MSISDN, Order status,
Error Description, Failed system etc. Majorly all data divided into two categories affected
Main Line Item [MLI] or affected Line item [LI], and their status wise count as below.
For MLI:
Row Labels Count
Connection Failure 8
Not Active 1
Provisioning Complete 69
Viper Failure 32
Viper Queue 30
Connection Queue 59
Grand Total 199
Table: 5.1
Table 5.1 shows status wise count of Main Line Item. It summarizes the total stuck count
of MLI and presented as table shown.
Interpretation:
Fig.5.1 is the pictorial representation of table 5.1. It depicts the total count and
major failure area in the system and needs to focus. This is the best way to get a complete
picture of a system in a glance.

Failed Line Item count

Viper Queue 30
Viper Failure 32
Provisioning Complete 69
Not Active 1
Connection Queue 59
Connection Failure 8
0 10 20 30 40 50 60 70 80
Fig.5.1

PAGE \* MERGEFORMAT 50 | Page

For LI:
Row Labels Count
Connection Failure
Connected Item 370
Connection Failure 240
Connection Queue 10
120

Connection Queue 115

Connected Item 80
Connection Failure 2
Connection Queue 33

Not Active 5
Connected Item 1
Not Active 3
Viper Failure 1
Provisioning Complete
Provisioning Complete 1391
Viper Failure 799
Viper Queue 155
Connection Queue 86
351

Viper Failure 87
Connected Item 29
Provisioning Complete 1
Viper Failure 51
Viper Queue 6

Viper Queue 875

Connected Item 92
Provisioning Complete 69
Viper Failure 5
Viper Queue 709
Grand Total 2843
Table 5.2

Interpretation:

Table 5.2 is the summary of affected Line items in given data. We receive one zip file
with all affected orders and line items. This table shows that total stuck line item count
stuck as per the failed state. In order there is only one Main Line Item and multiple Line
Items, hence Line Item count will always be greater than MLI count.

PAGE \* MERGEFORMAT 50 | Page

9 END OF THE DAY DASHBOARD:

This is the report, which collectively shows how many orders are processed by the team in
whole day, and how many are pending on other team’s actions. Pending order’s status,
their failed systems, Line items status and order type wise pending summary.

 Order inflow and processed status:

Inflow Processed Pending

Order Type
Orders Orders Orders
Bar/Unbar 225 225 0
Change MSISDN 351 349 2
Change MyZone 65 65 0
Change SIM 26 26 0
Change Tariff 354 334 20
Disconnection 450 448 2
EC 2 Postpay 24 24 0
EC 2 Prepay 29 29 0
Ex Prepay 21 21 0
General Modify Order 15 15 0
Modify VPN 45 45 0
New Connection 13 10 3
New EC 23 23 0
New Prepay 550 548 2
One-Off 200 198 2
Port In Postpay 8 7 1
Port Out 34 32 2
Postpay to Prepay 13 13 0
Reconnect 3 3 0
Renewal 54 54 0
Tranfer 10 10 0
Table: 5.3

Interpretation:

As shown in the table 5.3, there are total inflow orders processed orders and total
pending orders due to other system dependency. These are the total number of orders
received by Pending Order’s team. This count is calculated by adding four daily reports
from the system.

PAGE \* MERGEFORMAT 50 | Page

 600
400
200
0
Inflow Orders
Processed Orders
Pending Orders

Fig 5.3

 Pending order count on third party systems:

Third party system Count

ALU 3
BRM 8
ENT 2
NETWORK 1
SHOPS 3
USER 17
Table 5.4

ALU – Alca Lucent Provisioning CVC – Connections Group BRM – Billing and Retail Management

Interpretation:
These are the failed orders on different third party system’s pending for an action.
After taking actions from their side, Pending orders team may proceed to take actions from
their end.

Pending Orders
18
16
14
12
10
8
6
4
2
0
ALU BRM ENT NETWORK SHOPS USER

Fig5.4

PAGE \* MERGEFORMAT 50 | Page

 Line Item Status:

Count(*
LI Status )
Provisioning
Complete 54
Viper Queue 3
Viper Failure 39
Connection Queue 4
Connection Failure 30
Cancelled Item 10
Table 5.5
Interpretation:
Table 5.5 shows Pending Line Item’s count. This is the Pending Line item count
stuck in the system due to any reason. Mentioned are the statuses through which order gets
complete. This count includes failures and other dependent Line Items in the system.

LI Status
60

50

40

30

20

10

0
Provisioning Viper Queue Viper Failure Connection Connection Cancelled Item
Complete Queue Failure

Fig 5.5

PAGE \* MERGEFORMAT 50 | Page

 Total Order Wise status:

Order Status 2513

Completed 2470
Incomplete 32
Cancelled 9
Submitted 2
Table 5.6
Interpretation:
Table 5.6 shows status wise order count which gives us the top view on the system
and status of pending count. It has the summary of all status wise failed and stuck orders.

9
32 2

Completed
Incomplete
Cancelled
Submitted

2470

Fig 5.6

PAGE \* MERGEFORMAT 50 | Page

10 WEEKLY DASHBOARD

Week 1
Wednesda
y
Connected LI 24
VIP tickets, Bundle Bucket Issue 35
UBA Issue 20
Orders Stuck in Validation Failure 15
New Connection 50
One-Off, Modify Ebill, New Billing Account
Creation 800
GSM
Orders
Total Orders 6719
Progressed Orders 6677
Incomplete Orders 42
Table 5.7

The table shows the weekly resolved orders and other issues from different sources. Here
Oracle Siebel CRM is used as a ticketing tool to resolve requests.

800
600
400
200
0
LI ue ue r e on on
cte
d Iss Iss ilu cti ati
e t A Fa e r e
nn ck
e
UB n nn tC
Co Bu atio Co un
le lid w co
nd Va Ne Ac
Bu n g
s, ki llin
ket tuc Bi
tic r sS ew
VI
P de lil , N
Or Eb
ify
od
ff ,M
e-O
On

Fig. 5.7
PAGE \* MERGEFORMAT 50 | Page
 CHAPTER 6:
FINDINGS OF THE STUDY

PAGE \* MERGEFORMAT 50 | Page

KEY FINDINGS:

10. There are orders stuck in a system due to wrong data acceptance from CRM like
extra special character in a field or wrong offer name etc. These mistakes results
into failure on other systems.
11. Orders get stuck due to submitting wrong orders into the system for wrong request.
Such as, for adding an offer, Customer care representative raises change tariff
order, which has entirely different functionality.
12. Orders stuck due to system validations such as character length for different
systems varies as per their processing and system asynchronous alignment.
13. Some orders stuck due to middleware incompatibility to communicate with other
systems. As middleware is used the OSB which is Oracle’s product and other
systems are not from the Oracle’s suite. Hence compatibility should be manually
configured to tightly couple to each other.
14. Unmanaged inflow of orders. There is not scheduling system implemented at the
receiving end to manage the flow of orders.
15. There are no read accesses on of some of the processes. While taking actions from
CRM we need to make sure that the updated status of the MSISDN at different
processes. In current scenario we do not have access to check it by ourselves.
16. There is one screen named “No-Rules screen” which does not have any validations
on it and by using that screen CSR agents raising an order, which fails due to
wrong order creation.
17. As due to security issue, we cannot run tools from local machine, it is very difficult
to process on orders with slow speed.
18. Less automation implemented.

PAGE \* MERGEFORMAT 50 | Page

CHAPTER 7:
SUGGESTIONS

PAGE \* MERGEFORMAT 50 | Page

As per above observations there are multiple situations through which orders may stuck in
the system. But we can resolve it through applying multiple solutions on multiple
situations.
10. There is a need to revise data validations on order creation sources. Such as order
can be raised from App or portal with minimum inputs to system and other values
are configured in CRM.
11. Customer care executives need to be educated regarding order structure and
creation process.
12. There should be all backend validations to be applied on facing system such as
CRM.
13. While upgrading, patching, new deployments and releases we should consider the
effect of upgradation on other systems as well.
14. We have different sources of orders and we do not have any control on inflow of
the system. Whenever there are large number of bulk orders may get submitted,
managing the flow will result in system running in a smooth manner.
15. As the structure is very complicated, sometimes order will get completed without
going to some processes. Hence next time whenever order raise to change the
existing offer, the latest order fails. This results in raise in pending order count.
Need to simplify the architecture.
16. Need to manage the work amongst team. Current method is time consuming and
prone to dependencies as well as current approach is to resolve the order and not
problem.
17. There are different SLAs to different inflows of problems. Hence PO team has
multiple sources as well for checking the issues in systems.
18. Need to implement different scripts on servers and Remote Desktops to take
actions on bulk failed orders in one go.

PAGE \* MERGEFORMAT 50 | Page

CHAPTER 8:
CONCLUSION

PAGE \* MERGEFORMAT 50 | Page

There are different systems involved into the complete process. Every system works
independently and in an isolate manner. Every order comes with some request, whether it
may be for modification, new, renew or deletion. There are multiple order types involved
in this process, as per the customer’s requests. Every order type has some mandatory fields
at different internal systems. Hence every validation on internal systems should be applied
on face system [CRM]. All systems should be in sync with each other.

Also system must guide the end user and while applying such validations we should
consider that user may not be technical sound and s\he may or may not familiar with the
implemented process, hence multiple validations should be applicable to the face of the
application.

Entire order flow contains multiple sub processes hence these sub-processes are
interdependent on each other to fulfill the customer request. So as to make process efficient
and pro-active, we need to maintain compatibility and synchronization among all the
processes.

PAGE \* MERGEFORMAT 50 | Page

CHAPTER 9:

REFERENCES

PAGE \* MERGEFORMAT 50 | Page

 Paraskevi G., (2013), Standard Operating Procedure (SOP), Vodafone shared
services India Company operations document. 10-115.
 Vrtanoski, Jordan (2011), Order management system,
https://en.wikipedia.org/wiki/Order_management_system
 Dani Hao,All You Need to Know About Order Management And How to Speed
Up Your Procurement Timeline, procurify blogger site.
 https://blog.procurify.com/2018/03/13/need-know-order-management-speed-procurement-
timeline/

 Prashanth Krishnamurthy, Basics of Siebel Order Management and eConfigurator,

crmcog Blog.
 https://crmcog.com/basics-of-siebel-order-management-and-econfigurator/

PAGE \* MERGEFORMAT 50 | Page