At last week’s HRWorks conference, a recurring theme in our conversations was the distance between the people doing the work and the leadership teams making decisions about how that work should happen.
As we demonstrated Intersect’s Employment Equity solution, the discussion often moved beyond the software itself. Delegates spoke about the practical difficulties of introducing more efficient processes when the people approving the investment had limited visibility of the work involved in the current approach.
From a leadership perspective, the reports get completed and the deadlines are met, so there may be little reason to question how the business gets there. For the person responsible, however, that same outcome might depend on weeks of chasing employee information, correcting incomplete records and copying the same data between spreadsheets and reports.
That difference in perspective makes software adoption considerably harder. Before a business can properly assess a better way of working, it needs a shared understanding of the work it is already asking people to do.
The completed report tells only part of the story
A report reaching management on time confirms that someone delivered it. It does not necessarily reveal whether the process was efficient, repeatable or dependent on one person’s willingness to keep following up until everything came together.
Consider an HR practitioner preparing Employment Equity information. Before management sees anything ready for review, that person may have requested employee details from several departments, reconciled conflicting records, queried missing information and checked that corrections have carried through to the relevant working documents. For designated employers, that work feeds directly into the EEA2 and EEA4 reports submitted to the Department of Employment and Labour.
By the time the report reaches leadership, most of that activity has disappeared from view. The finished document looks orderly because someone has absorbed the disorder along the way.
When this happens repeatedly, the business can develop an inaccurate picture of its own processes. Management sees a function that is delivering, while the employee experiences a process that is becoming increasingly difficult to sustain alongside their other responsibilities. That inaccurate picture is one of the quieter reasons software adoption stalls.
The employee’s competence can unintentionally hide the need for improvement. The better they become at making the process work, the less visible its weaknesses become.
Software adoption becomes harder when people are solving different problems
Leadership and operational employees can enter the same software discussion with very different expectations.
An executive might want better reporting, clearer oversight and confidence that the business is meeting its obligations. The employee responsible for preparing the information might want to stop capturing the same details in several places, reduce the number of follow-up emails and know which version of a record they can rely on.
These priorities are connected, but the connection needs to be explained. If the conversation focuses only on convenience for the employee, leadership may struggle to understand the business case. If it focuses only on management dashboards, employees may question whether the proposed system will improve their working day. Making that connection visible is often the first real step in software adoption.
A useful software adoption discussion follows the work from beginning to end. It considers how information is collected, who checks it, where it moves next and how leadership eventually uses it to make decisions.
That gives everyone a common basis for evaluating the investment. The question becomes whether the proposed solution improves the process sufficiently to justify its cost, implementation effort and ongoing use.
Manual workarounds can look like established business processes
One of the difficulties in changing a process is that people become accustomed to the workarounds needed to keep it going.
A spreadsheet is created because a system does not contain all the required information. Another spreadsheet follows because a different report needs the information arranged differently. Email becomes the approval mechanism, while someone’s personal checklist becomes the only reliable record of what still needs attention.
Over time, these arrangements can become so familiar that nobody remembers which parts were deliberate choices and which were temporary fixes.
This complicates automation and software adoption because the business may try to reproduce every existing step in a new system without first asking whether that step is still necessary. It also complicates the purchasing decision, as leadership may compare a software subscription with the apparent cost of continuing to use spreadsheets.
The spreadsheets themselves may cost very little, but maintaining them requires time. So do reconciling different versions, investigating discrepancies and explaining why a report has changed since it was last reviewed.
Those activities belong in the assessment of the current process. Otherwise, the business is comparing a visible software expense with an incomplete picture of what it already spends to get the work done. Leaving those costs out makes any software adoption business case look weaker than it really is.
Employee concerns deserve closer attention during change
The disconnect can also work in the other direction, particularly when leadership selects a system before involving the employees who will use it.
From management’s perspective, the decision may be a sensible investment in efficiency. From the employee’s perspective, it may arrive as another responsibility added to an already full workload, with limited explanation of how the transition will happen.
Questions about data quality, training, duplicated work or implementation timing can then be interpreted as resistance to change. Some of those questions may identify practical problems that need to be resolved before the new process can succeed.
For example, an HR employee who asks who will clean the existing employee records is raising an important implementation issue. If that responsibility remains unclear, the business may move incomplete information into a new system and discover that the same queries still need to be resolved.
Involving employees early gives the business an opportunity to distinguish between concerns that need practical answers, preferences that can be accommodated and habits that will need to change. It also gives employees a clearer understanding of what leadership is trying to achieve and where their input can influence the outcome. It also turns software adoption into something employees help shape rather than something done to them.
HR process automation needs decisions about responsibility
Software adoption creates an opportunity to improve a process, but the business still needs to decide how people will work within it.
If employee information is incomplete, somebody needs responsibility for obtaining it. If a record is incorrect, there needs to be an agreed way to correct it. If a report requires review, the reviewer needs to know what they are expected to check and when their input is due.
Without those decisions, employees can end up running the old process alongside the new system. They continue maintaining their spreadsheets because they are unsure whether everyone is using the software consistently, and they keep sending follow-up emails because responsibilities remain unclear.
That duplication can undermine confidence in the change. Leadership sees limited improvement, while employees feel they are doing more administration than before.
A workable transition therefore needs agreement on which system holds the authoritative information, who maintains it and when the previous method will be retired. It also needs enough time for people to learn the new process while continuing to meet their existing responsibilities. Without that agreement, software adoption tends to leave a new tool running alongside the old workarounds.
How to close the gap before software adoption
A useful starting point is to ask an employee to walk leadership through one recurring task using a recent, real example.
For an Employment Equity process, that might mean following the information from the initial request through to management review. The purpose is to understand what actually happens, including the follow-ups, corrections and handovers that are easy to leave out of a process description.
The discussion should establish:
- Where the information comes from: Identify the people, systems and documents needed to complete the task.
- Where work is repeated: Find information that is captured, checked or reformatted more than once.
- Where progress gets delayed: Separate delays caused by missing data, unclear responsibility, approvals and system limitations.
- What the work requires: Record the time spent collecting, correcting and preparing information, as well as reviewing the final output.
- What employees need from a new process: Include practical requirements such as access, training and a manageable transition.
- What leadership needs to see: Agree on the reporting and oversight required to assess progress and make decisions.
- How improvement will be measured: Choose a few relevant measures, such as preparation time, outstanding information or the number of corrections needed before approval.
This gives the business something concrete to take into a demonstration. Instead of asking whether the software has an impressive list of features, the team can ask the provider to show how it handles the work they have just mapped. It also gives you a baseline for measuring whether software adoption is delivering the improvement you expected.
Where connected compliance software fits
At Intersect, we approach compliance as connected work involving information, responsibilities, documents and reporting. Our platform brings compliance workflows and organisational information together, including Employment Equity workflows and reporting. intersectconnect.com
The relevance of that approach becomes clearer when leadership and employees examine the same process together. An HR practitioner may be focused on the difficulty of assembling reliable employee information, while leadership needs confidence in the reporting that follows. Both depend on the quality of the underlying information and the process used to maintain it.
For a business considering software adoption, the demonstration should therefore include the people who perform the work and someone who can make decisions about the process. That creates space to assess operational detail and management requirements together, while identifying any changes the business itself will need to make.
A better transition starts with understanding the working day
The conversations at HRWorks highlighted how difficult it is to improve a process when the people involved have different views of what it takes to deliver.
Leadership may see a completed report and assume the current approach is adequate. Employees may see the opportunity for improvement but struggle to explain the full business impact of the work happening behind that report. Neither perspective provides a complete basis for deciding what should change.
Bringing those perspectives together makes the software decision more useful. It gives leadership a clearer understanding of where time and effort are going, and gives employees a meaningful role in shaping a process they will be expected to use. That shared picture is what makes software adoption last.
If your team is spending too much time collecting information, reconciling records and preparing compliance reports, book an Intersect demonstration. Bring the person doing the work and the person responsible for approving improvements, so we can explore the process from both perspectives.
