Car acquisition

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.

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 funnel, closer to a successful deal. The interesting part is, that about 10% of visits actually create an initial inquiry. The rest of the visits are customers that leave the website without any desire to drive cars of the company.

Subprocess - inquiry

Here the inquiry is processed. many of the inquiries are not suitable to continue, and so these customers do not have the opportunity tp drive any car - either from their matter, or matter of the company. Detailed information will be available in the subtask description.

Delay

When the inquiry is finished, it is necessary to agree with the customer on the date of car delivery. This takes Log(2, 0.5) days.

Subprocess - car delivery

All necessary steps for converting customers and cars to new entity, customer driving a car. Detailed information will be available in the subtask description.

Delay - car driving

This is when the car is used and driven by the customer. As the company does not offer only fix-term leasing, but also one with resilient leasing length, it usually takes Nor(10, 3) months before the customer decides to return the car.

Subprocess - car return

Administration takes place so that the contract between the customer and the company is legally over. Detailed information will be available in the subtask description.

Split

As the entity `customer driving car` must be divided back to the two original entities, the split is used. The two entities are the car, and the customer - the customers are then at the end of the whole process, which is different ending from the cars.

Branch - is car usable?

At this point, the car is returned from the customer and is in used shape. Now it necessary to decide whether the car must be destroyed, or if the shape is still appropriate for leasing. Fortunately, 90% of the cars can be reused, meaning they can be used again in the long term when the leasing demand is higher.

Delay - car wash

To archive the most satisfaction, the car must be delivered clean and ready, so after it is returned, the car is given a wash, which is processed by an external company and takes 3 hours.

Lower level - inquiry

Lower level - car delivery

Branch

In car delivery process,car and customer are both input entities. for this reason, they must be firstly split

Delay - car wash

The car gets a quick outside wash before handed to the customer. It takes the external company about 2 hours to do so.

Assemble - car transfer

This is an activity that is not dependent on a trigger, but rather on the existence of both the car and the customer at the same time. When this happens, a new entity is released, marking that customer takes the car, and drives out of the parking lot as a new entity, "customer driving car".

Lower level - car return

Delay - inspect car, sign return protocol

During the car return, not much happens. The car is inspected for any noticeable damage, the return protocol is signed, and the customer leaves on foot. This delay takes 30 minutes.

Code

File:Car-aquission-model.spm