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

The customer must pass many checks to get to the other side of the inquiry process. some of them are in the power of the company, and some are dependant only on the customer.

Delay - inquiry specification

Tweaking the colour, the interior. This delay takes Log(2, 0.7) hours. After the tweaking, the customer receives a call, and if he changes mind, he is out of the process. Fortunately, this is not that common, about 0.5% of people leave the inquiry process here.

Delay - scoring

The company makes effort to find out if the customer has sufficient payment morale if he will not crash the car after two weeks, or any other event would occur, that would endanger the company, or at least make a problem.

20% of customers do not pass the scoring.

This scoring process takes Log(4, 0.5) hours, and if the customer does not pass the required minimum, he cannot continue in the inquiry process.

Delay - sends driving licence, identification card

It is necessary to be sure if the customer can drive the car, has the proper driving licence, and is old enough to be enough responsible. It takes the customers Nor(1, 2) days to send the documents and the company to process them and 60% of customers pass this delay.

Delay - receives contract

In the last step, the customer passes all the checks and can sign the contract provided by the company. however even in these cases, there are some customers that take their time to do this, and even some that do never sign. It takes Nor(4,1) days to sign, scan, send and process the contract with a 90% success rate.

Lower level - car delivery

Branch

In the 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 for about 2 hours to do so.

Mege

Both customer and car merge into one connection, ready to assemble

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.

Results

In first run, car delivery was set to 20 cars a day. This resulted in unfulfilled demand, as customers remained in the system in the car transfer:

                                         Total     Remaining     Total     Total
Activity Names      Entity Names         Accepted  In Act.       Exited    Not Processed
car transfer11      car                      8738          0       8738          0
car transfer11      customer driving c          0          0       8738          0
car transfer11      customer                10598       1860       8738          0

On second run, car delivery was planned for 30 cars per day to even out the excess demand. This resulted in a different outcome, where cars remained in the system:

                                         Total     Remaining     Total     Total
Activity Names      Entity Names         Accepted  In Act.       Exited    Not Processed
car transfer11      car                     12859       2556      10303          0
car transfer11      customer driving c          0          0      10303          0
car transfer11      customer                10303          0      10303          0

Car driving is 0 on accepted in these results, as they were on the output of this activity. What is more interesting, SIMPROCESS sees the entities which were input for the assembly (customer and car) on the output, however these entities were consumed in the process of assembly.

On additional (manual) runs these results were similar - either too many cars, or too little customers. 25 cars per day seemed like the optimum for this simulation.

Conclusion

In Conclusion, the simulation model accurately representing the business model has its flaws.

As customer demand is not easily predictable, the model itself cannot be 100% accurate. at every point of the simulation, the values are approximated as close to the reality as possible, but the future is never certain.

If the results are correct, we can say (albeit with certain accuracy) that the delivery of cars is not sufficient with all the other variables being stable throughout the time. I'd recommend changing the delivery schedule from 20 cars per day to 25 cars per day.

Possibly more benefit would be handling cars as a resource which can be drawn throughout the time and its usage would relate to the customer demand. However, this approach cannot be applied to the whole simulation (and additionally to the business model), as the process of acquiring the cars for the business must be planned ahead. The car delivery takes some time and potentially some unexpected expenses.

To sum up this study, I'd like to point out that calculating customer demand and car delivery schedule is very difficult. The future is always uncertain, and the business should respond flexibly to the actual conditions. If not every day, planning to quartiles or even months would drastically optimize the business process.

Code

File:Car-aquission-model.spm