Difference between revisions of "Car acquisition"

From Simulace.info
Jump to: navigation, search
(v3)
(v4)
Line 17: Line 17:
 
As a tool to model the system and then analyze different scenarios, SIMPROCESS was used. There are multiple reasons for this, mainly that the system is an array of intertwined processes where at the start there is a customer which wants a car, and at the end, there is a customer that returned the car and has a pleasant experience the whole time. A hierarchical modelling tool that combines process mapping and discrete-event simulation surely find usage for this case.
 
As a tool to model the system and then analyze different scenarios, SIMPROCESS was used. There are multiple reasons for this, mainly that the system is an array of intertwined processes where at the start there is a customer which wants a car, and at the end, there is a customer that returned the car and has a pleasant experience the whole time. A hierarchical modelling tool that combines process mapping and discrete-event simulation surely find usage for this case.
  
As the company currently works in year-ahead planning, the simulation was set to run in a one-year window, from 1.1.2021 until 1.1.2022. the data applied in the model are mostly based on outputs from systems the company uses daily, and so the values are based on datasets with a certain degree of accuracy. Some of the data come from plans for the following year - this includes the car delivery schedule and personal changes in the company.  
+
As the company currently works in year-ahead planning, the simulation was set to single run in a one-year window, from 1.1.2021 until 1.1.2022. the data applied in the model are mostly based on outputs from systems the company uses daily, and so the values are based on datasets with a certain degree of accuracy. Some of the data come from plans for the following year - this includes the car delivery schedule and personal changes in the company.  
  
 
=Model=
 
=Model=
Line 31: Line 31:
 
[[File:High.PNG]]
 
[[File:High.PNG]]
  
===Generator - customer ===
+
To explain the model in detail, firstly the generators will be described, and then all the other activities through the red path of the model - this means that if the entity goes off the red path, its outcome will be described on last red path activity. each lower level subprocess will be explained in its separate chapter.
  
===Generator - car ===  
+
===Generator - customer===
 +
 
 +
Customer is a type of entity. it is released In quantity of one, with an interval of Log(2, 0.5) minutes. This approaches data from the access logs. As the access log is not easy to parse and extract the data, and to create a statistical analysis on the time entries, this approximation was chosen.
 +
 
 +
===Generator - car===  
 +
 
 +
Cars are generated accordingly with plans for car deliveries in the following year. Cars will be introduced to the system every day, in a number of 20 cars a day. This "dry start" will surely be a deficiency of the model, as there will be a surplus of the cars in the beginning. but after some time (~ a month) the surplus equalises with the demand. Similar behaviour is with customers filling up the model. However, the daily deliveries of cars are actually a real-world planned case, and so the simulation reflects this.
 +
 
 +
A slight deficiency of this model is the time that it takes for the generated entities to fill up the model - this could be improved with warming up the simulation.
 +
 
 +
===Branch - visit===
 +
 
 +
At the start of the customer introduction to the business process, the customer himself must create the inquiry, so that the company can walk him down the conversion tunel, closer to a successful deal. The interesting part is, that about 10% of visits actually create an initial inquiry. the rest of the
  
 
=Results=
 
=Results=

Revision as of 21:48, 19 January 2021

When a regular person wants to rent or lease a car, he usually does not usually know how much work does it take on the background. From his point of view, he has the need to use a car, so he decides whether to buy one or lease one if this is a long term need. In such cases, a long term solution is needed.

So upon choosing the car he dreams about, the customer fills the inquiry form, signs some papers and leaves with the car.

Well, sort of. On the background, there are many steps that ensure customer happiness with the service, and also the whole process which ensures that the customer is reliable enough to temporarily leave him with a car - this car might be worth hundreds of thousands CZK, or even one or two million CZK.

Problem definition

As mentioned in the introduction, there are many steps on each part of the system, and that is the customer and the lessor. Some of these steps need both parties to cooperate (exchange of documents, car delivery) or are cared about by one or another party. The lessor can wash the car, and the customer for example uses the car.

Leasing a car is basically a car-subscription model. Instead of the common approach where one buys a car and scrapes it after ten years, or even the approach of buying a used one and selling it in few months, a subscription is something that many companies choose over one-time payments. This way people are not forced to save money or to get into debt, but they can give part of their monthly income to consume a product. The car industry is not common for such new-school approaches, but time goes on, and so does the trends.

This paper describes problems of the current setup and analyzes potential bottlenecks of the system. Worth mentioning is also the capabilities of the system, required to predict the necessary steps for the future development of the company.

Method

As a tool to model the system and then analyze different scenarios, SIMPROCESS was used. There are multiple reasons for this, mainly that the system is an array of intertwined processes where at the start there is a customer which wants a car, and at the end, there is a customer that returned the car and has a pleasant experience the whole time. A hierarchical modelling tool that combines process mapping and discrete-event simulation surely find usage for this case.

As the company currently works in year-ahead planning, the simulation was set to single run in a one-year window, from 1.1.2021 until 1.1.2022. the data applied in the model are mostly based on outputs from systems the company uses daily, and so the values are based on datasets with a certain degree of accuracy. Some of the data come from plans for the following year - this includes the car delivery schedule and personal changes in the company.

Model

The Model is divided into two layers. The first layer incorporates the basic activities, and also three subprocesses which are on the lower level.

higher level

At the higher level, two entity generators are located, 10 other activities and the three subprocesses mentioned previously.

The customer flow is merged with car flow at the car delivery, where also returned cars are reused. This merge is then split when the car is returned, and the customer leaves the system, and the car is reused is usable.

High.PNG

To explain the model in detail, firstly the generators will be described, and then all the other activities through the red path of the model - this means that if the entity goes off the red path, its outcome will be described on last red path activity. each lower level subprocess will be explained in its separate chapter.

Generator - customer

Customer is a type of entity. it is released In quantity of one, with an interval of Log(2, 0.5) minutes. This approaches data from the access logs. As the access log is not easy to parse and extract the data, and to create a statistical analysis on the time entries, this approximation was chosen.

Generator - car

Cars are generated accordingly with plans for car deliveries in the following year. Cars will be introduced to the system every day, in a number of 20 cars a day. This "dry start" will surely be a deficiency of the model, as there will be a surplus of the cars in the beginning. but after some time (~ a month) the surplus equalises with the demand. Similar behaviour is with customers filling up the model. However, the daily deliveries of cars are actually a real-world planned case, and so the simulation reflects this.

A slight deficiency of this model is the time that it takes for the generated entities to fill up the model - this could be improved with warming up the simulation.

Branch - visit

At the start of the customer introduction to the business process, the customer himself must create the inquiry, so that the company can walk him down the conversion tunel, closer to a successful deal. The interesting part is, that about 10% of visits actually create an initial inquiry. the rest of the

Results

Conclusion

Code