Dealer Management System (DMS) is a complex application that serves as the platform to manage auto dealerships, connecting different functional areas, such as sales of new and used cars, Collections even up to repurchase/repossession, Service Departments, and Warehouse Systems. It should not be confused to say only auto dealers, any company where autos, be it sales, parts, service, or even usage (such as rentals) would be well served by DMS. Two product teams from Jimmy Technologies have been involved in the development of the DMS known as OMNETIC. OMNETIC is the central part of several interconnected applications of the EAG Group. During the development of the basic and key functions of OMNETIC, we identified several lessons learned:
Before we started planning and defining the requirements for such a dealership application, we had to answer business questions, such as:
- What makes a dealership network successful?
- Revenue from car sales and services minus the cost of the vehicle and consumables. This revenue consists of three parts:
- What share from the sale of autos the dealership would earn, calculated as the difference between the sale price and their purchase price. This share is referred to as the trade surcharge.
- Receipts for services rendered and work performed (vehicle repair, tire fitting, sale of additional equipment, and so on)
- Other income from non-core activities (income and expenses from unsold operations, sale of surplus equipment, transfer of temporarily unused premises and facilities for rent, sale of auto club memberships, etc.)
Based on these lessons we knew the DMS is required to be interconnected with an accounting system. Depending on the strategy/ies of each dealer, DMS can have a built-in accounting system or connect to third-party applications via API integration. In both cases, data collection and reporting need to comply with the standards of accounting, such as IFRS or GAAP. Such standardization is used to identify typical and familiar solutions for accountants. This greatly reduces the preparation time of development and allows easier collection of information from DMS users.
Different specializations of dealer centers and their structures determine the specification of product requirements and functionalities.
It is necessary to define these aspects at the start of the various development phases. After that, one can recognize options in approach: dealers who deal in aftermarket positions with a wide range of brands, or certified dealers who specialize in particular brand/s. To not overcomplicate here, we only examine these two binary usages. This affects basic functionality and further development and later phases. For example, DMS built for use by certified dealerships selling new cars has some interesting aspects like ordering a car, configuration of models and amenities, possible modifications, concluding the final sales contract, and handing over/retrieving the car. From the car buyer's perspective, this is a very safe way to purchase a vehicle, and the dealer limits their exposure to too many units on their lots. Another interesting aspect to this for buyers are calculators for and links to financing; allowing dealers additional revenue streams for loan origination referrals, perhaps with origination fees.
One can easily imagine the various positions and departments which we interacted with and who used the application. The result has been different interfaces for the various roles. Creation of these led to each needing definition, and through development, their own set of user stories, sprints, phases, and flows built in proper design.
Don’t try to cover all scenarios initially
Using Agile Methodology, it should be clear to recognize the need for basic functionalities rather than trying to determine the final view of the DMS. Taking on too much at once will result in a complicated flow and a sense of futility trying to cover the maximum number of scenarios, many of which would only be reworked later. Iteration by iteration of each functionality can involve the various users’ processes, observation on-site, and even individual interviews to make the various interfaces or functions. To proceed into every aspect the dealership will need without taking into account the suggestions and comments of those who work with the final product will not bring the needed results and happiness. This would only be viewed as a failure if pursued.
Trying to sell and buy a car with developers
Despite the popularity of cars, not every developer has the experience of buying a car, and even fewer have experience in selling cars. The specifics of the automotive dealership world are alien to most, in fact, much less those working in IT. This leads to the impression that, for the developer, the application is reduced to buttons and tables. For development teams to consciously implement the specific and required functionalities, you need to play the seller-buyer game with them and describe the entire process. Consultation driving a clear output with interviews of the dealerships’ staff, various roles, needs, and the requirements of data must prove first to the development team what is needed in development. This consultation must be able to take into account as many aspects of the world of the car dealer as possible.
Test the selling and buying processes with the dealers
The environment must be set up to create the inflow of as many pieces of feedback from all users; employees, vendors, and especially dealer clients. This will flush out the collecting of bugs in the program, from surface issues to the most unimaginable. One can imagine the feedback loops of direct communication with users during interviews, creating support services, placing feedback links directly in the application, and creating an email mailbox where users can write, and/or send survey requests via emails used for login creation.
Questions about unexpected user behaviors and the “hacking” of processes are commonplace with many IT projects, but the loss of process design and discipline in this segment can be enormous. For instance, by structuring the purchasing process in a certain way, you invite users to “hack the system”. Imagine a process requiring a photo in data entry to document the vehicle into a working file, human nature will engage and then dealership employees will have several files of photos they will start adding in place of the "mandatory" photo. Such issues lead to bad data in the application, which reduces the value of the software. Training with a clear understanding of what such shortcuts cause, and allowing the DMS user or company managers to customize mandatory requirements themselves.
A likely smarter approach is to not complicate the system and processes used with it. Reduce the introduction of information/interaction with third-party applications. If information can be obtained from the outside, then leave a link to it in the place where the user will look. Of course, tying in APIs to move data seamlessly is even better, but will lock in commitment to those products. Don't waste time and money duplicating unimportant information, instead use that time more wisely on developing the exact functionality needed.
Let's take a closer look at some of the specifics of DMS development
Dealership businesses are complex and include Automotive, Accounting, Logistics, Sales, Service Departments and so much more
Documentation of the software solutions and processes is key to the overall acceptance and usage. One must document the product and technical aspects of each solution that is added to the platform, regardless of framework. This is a requirement of any large project, but the complexity of the dealerships proves the widespread use of data across the various departments, suppliers, and vendor services such as for taxes and legal. Missing documentation might lead to white spots with real users. At best, this may lead to a lack of understanding of the product, while at worst it will lead to errors in the work and cost increases to the project.
DMS is all about data, and photos are front and center
When and where the photo/s is/are needed in the various processes is key in documentation, training, and avoidance of the aforementioned behavior of process “hacking”. Using data, including photos, is the reason for software and entire platforms for industries like automotive. Photos of the cars used in handing over of responsibility, such as from (in the case of a used car/trade-in) or to the customer, for repairs, financing files, and of course in advertising. All this imposes requirements on storage: the size and number of files. It is also necessary to consider the convenient behavior of uploading and managing photos.
Allow users to track a vehicle's history
What else if not to track the product through the various points of the dealership business, the history of the car sets how and where that car can be sold and of course its price. With this data accessible to all users the value of the system can be most widespread. It is easy to imagine aspects of importance: the number of owners, mileage, maintenance, and accidents.
Plan your development and deployment phases
We have all experienced times when the computer runs slow or otherwise “doesn't work”. Live and real-time disruptions must be kept to a minimum and no interruption should ever occur during working hours. Planning simply means you will work with test versions called Staging Environments. Staging allows you to make updates and test new versions without fear of affecting the user. You can also calculate the greatest load on the databases and other “strains” such as on infrastructure.
It is necessary to find a balance between the speed of development and the size of the development teams. Developing a DMS is complex and requires a lot of time and patience. An error or bug can cost your customers a lot of money. The fewer people working on it, the more time it takes. Achieving the right cadences and budgets will be different with each dealership.
The most significant conclusions are:
1. testing. In any development project, Quality Assurance testing and the fixing of bugs take a significant amount of time. Be cognizant of the effects upon the timing of releases, and the expenses which bugs cause.
2. The idea that "we know how the application we want to create should appear" is only partially true. Active users and testers are sure to make a meaningful contribution to the development of the application. Don't neglect to communicate with them, Keep the end in mind, but it is necessary to start from each beginning, defined as the User Stories.
3. Interactive building of the solutions will keep you from losses of money, rework, and disaffected users. Building solutions that are too complex, trying to cover all aspects of the work, is likely to be expensive and outdated upon completion. Use caution not to create long development times or complex solutions that are incomprehensible to the user.
4. The purpose of any business is to sell its products and services. This usually always requires people, employees, with the best available qualifications, the processes of work, integration, and relation of the various departments of product/service Sales, Delivery, and Finance, must be enhanced by software. In the Automotive dealership world, DMS is that software solution.
At Jimmy, we have the experience of 2.5 years of work in DMS development on OMNETIC. There are not many comprehensive solutions on the market that cover all possible scenarios for a dealership network. Developing such an application requires a lot of time and money. Also, developing a DMS requires an understanding of the specifics of the automotive industry’s offline and online sales processes. Be sure to talk with us when you are ready to implement this or any digital environment into your work.
Reach out for more information.
Pavel Kukolev, product owner
