The new apprenticeship service adds employers into the payment process, creating another layer of complexity in the system.
Payments through the apprenticeship service need to tie in with the existing funding system run by the SFA. So that public money is protected, there’s a complex set of funding rules already in place governing the relationships between training providers and the SFA.
From April, employers will choose their training provider and ask the SFA through the service to pay the provider from funds in their digital account. So there are now 3 parties to the payment process: the employer, the provider and the SFA.
The existing system is based around the individualised learner record (ILR). Each month, training providers send the SFA an updated ILR. This is a record of the training they’ve delivered and who they’ve delivered it to.
Employers now have influence over the payments that go out. They can stop payment if there’s a disagreement of some kind with the provider. For example, if there’s a dispute about the quality of training or content being delivered.
In the new service, employer and provider both need to enter and agree on the following data, which is then used to match ILR details to those held separately by the employer:
1. Unique learner number
3. Apprenticeship course/ details
4. Start date - learner can’t start before the agreed date
5. Training provider
To build the payments software, we needed to consider all scenarios. The simplest scenario is a learner starting and completing on time. But things can deviate a lot from the initial plan. For example, a learner could start later than intended, or change course mid way through. Or the employer could change training provider.
We use a process called Specification by example to ensure everyone working on the development team understands all possible scenarios. We run workshops with policy people and people who define the SFA’s funding rules, and then ensure that the artefacts we create look very similar to the screenshots and tables that have been produced.
This system allows us to make sure we’re all talking about the same thing and reduces the amount of translation. Because that’s when bugs creep into the system.
The rules and specifications we’re working with are all open source. Anyone from outside can actually see us building this. All of the stakeholders should be able to recognise the rules that they discussed and check against the software that’s been developed.
It’s a very open way of working that’s quite different to how the SFA used to develop its funding system. We’ve never had this level of transparency before. The SFA already publishes these funding rules so it’s not putting any new policy information in the public domain.
From here to infinity
You can actually build a system like this for eternity. We don’t even know where the bottom is. You can make it handle more and more complex cases. An apprentice can change employer, take a break and the price of his training can be renegotiated. Key stakeholders within the SFA are intending to scale up this approach to be used in the development of all funding systems - not just apprenticeships. This approach is a clear improvement on existing business processes.
These things compound, you get increasing layers of complexity. At some point we have to stop and say “do a manual payment”. We know the big things we have to do, but the edges are quite fuzzy. There are people here who’d like to build the payments engine forever. But that doesn’t fit in with the April deadline!