How to develop your own temporary Staffing recruitment software
Let’s face it: that is always going to depend on how big you are. So what are the figures?
Typically a software development company with any degree of longevity will have invested between a quarter of a million and two million pounds developing agency staff software. This includes essential testing, then refining the features as the temporary staff management processes and market evolves. Testing again, updating again due to changes in the law or regulations and then re-testing.
Over the last 10 years, regulation changes have been a more than annual event. With layers of bureaucracy continually thickening, it’s not ever likely to decrease. Essential continued development means that is a lot of your profit to absorb. You can buy or lease software at a fraction of this cost yearly and even or perhaps especially over a ten year period.
You may say “I don’t need all the features they have” and “I need some features they don’t have”. I want “perfect” software for my temp staff supply agency niche. Unfortunately the world does not stand still and this makes for a “perfect” moving target for "perfect" software.
So there some things to consider when you are developing your perfect staff agency software:
You are specifying it. Ultimately your consultants and your bottom line are testing it. To be fair this occurs to some degree for any new software. Fortunately for any group of customers, the live implimentation process is spread across a much wider customer base. The commercial customer probably only "beta tests" the features they specifically asked for.
Who is going to write your TemporaryStaff Agency software? An indivual, a team of short term contract developers or a specialist sofware develpment company? If they are a specialist company do they know your industry so they can spot the questions you should ask in developer speak? What sort of contract are they on? Is it a fixed price contract or are you writing an open cheque? Is Any credible Development Company likely to enter into a fixed price contract without an exhaustive and complete description including test cases? A credible developer will want to prove they have done exactly what you specified so they can demand payment. This is irrespective of the product meeting your actual needs as opposed to the ones you specified in the initial document. This is not unethical or immoral, you entered willingly into a business contract and they have fulfilled their part of it (or gone bust which leaves you out on the end of a pier).
Let us take a very simple starting example:
You specify that when you record a customer’s request for shift to be filled by your agency, you take the customer’s name, the location to be worked, the dates, the times and any compliance checks necessary for that job. This is fine and simple and the developer agrees that any issues are fixed within a year free of charge. Although compliance checks do change, let us assume no authority makes any new rules. The compliance checks you specified are recorded, properly checked and met. Just over a year down the road the database performance degrades. Is it that someone has hacked into your system? Is it a hardware fault? Is it just a matter of the number of records that need to be checked by your system? How do you find out? Is it simply that it’s a lot easier to find something when you are choosing from a few dozen or even hundred records but when it comes to approaching or exceed a thousand then the completely acceptable half second for under a hundred becomes 10x half a second or 5 seconds when there are ten times as many record to check?
So how many shifts do you have? 1,000, 10,000 or with some Ava systems 1 Million plus? So you need to test with the number of shifts, customers and employees that you expect to have 3, 4, 5 or more years down the road. Where does this test data come from? It has to be you because are you are specifying the system.
So you are now happy that the system works with not only a small amount of data but real amounts in every part of your system and it gives as good a response as something you could buy off the shelf.
One of the reasons for any system is to minimise expensive bookkeeping or accounting efforts and leverage your consultants’ time. You want to put data in once and everything to come out the end, correct? Minimising expensive bookkeeping is one of the main areas where your system will pay for itself. So your perfect system will be calculating pay (or generate statements for self-invoicing limited companies) and customer invoices. It will submit mandatory RTI information to HMRC and avoid their fines. The system will be submitting payment details to your bank so avoiding a substantial part of your hard erned profit margin going to factoring or accounting companies. So passing HMRC tests this year is a must. If and when there is a failure with next year’s HRMC format, your departed developers will fix it the same day? Its what HMRC demands. Best you keep a developer on and adding to your costs?
Of course there is a solution. You could take a developed Temporary Staffing package from a willing company and ask them to add the specialist bits you need. The day to day updates to ensure general compliance will be covered under their standard commitment to their product and you will only need to cover special features you alone will require. You can even have access to their code through a 3rd party software escrow process.