Why Enterprise HR Software Should Adapt to Your Processes

Every enterprise HR software project reaches the same moment. The implementation team maps a real process, say how a transfer between two plants is approved, and finds that the system does it differently. Someone then says the sentence that decides the fate of the project: "The system does it this way; you should change your process."

Sometimes that is good advice. Many HR processes carry years of accumulated exceptions that nobody would design on purpose, and a new system is a fair occasion to drop them. But often the process exists for a reason: a legal requirement, a union agreement, a management structure that reflects how the company actually makes decisions. Bending those to fit a software vendor's default is not simplification. It is a slow transfer of operational control from HR to the tool.

This article is about telling the two cases apart. It looks at the four areas where process fit is usually decided (approval chains, organisational structures, appraisal sheets and letter templates), explains where standardisation is genuinely right, and gives a practical way to test configurability in a demo before you sign anything.

Where the "change your process" advice comes from

Global suites were mostly designed around a reference model of a company: one legal entity per country, a flat manager hierarchy, an annual performance cycle with a single rating scale, and a handful of English document templates. The model is not wrong. It is simply narrower than the organisations that buy the software.

When a customer's process falls outside the model, the vendor has two options. It can write custom code, which is expensive and breaks on upgrades, or it can ask the customer to change. Asking the customer to change is cheaper for the vendor, so it becomes the standard advice, and it is dressed up as "best practice". The important question for a buyer is not whether the advice is sincere. It is whether the system offers a third option: configuration by HR staff, without code, that keeps the customer's process intact.

Approval chains: the process that touches everyone

Approval chains are the first place to look because every employee meets them. A leave request, an overtime claim, a salary advance, a transfer, a resignation: each has its own route through the organisation, and the routes are rarely identical. Leave may go to the direct manager only. An advance may need the department head and a finance controller. A resignation may need HR to acknowledge it before the manager can act.

In a manufacturing company the chains get more specific. A shift supervisor approves attendance corrections for his own line but not for the neighbouring one. A plant manager approves transfers within the plant, while transfers between plants go to the group HR director. A request above a certain amount jumps a level. If the system only supports "manager, then manager's manager", these rules have to be enforced by email and memory, which is exactly what the software was meant to remove.

What to look for is a chain designer that expresses routing by position, grade, entity, request type and amount, with delegation for absence and escalation on delay. In Orgarise, approval chains are built in the Organizational Management module with a designer, and the same chain definitions drive the requests employees submit through self-service, so the route HR designed is the route the request actually takes.

Organisational structures: entities, positions and grades

The second area is the structure the chains run on. Enterprises in Egypt and the Gulf typically hold several legal entities, sometimes in two countries, each with its own payroll rules, and an operational structure of plants, sites, departments and lines that does not map neatly onto the legal one. A position may report to one manager operationally and to another for cost purposes. A grade structure may differ between the head office and the factories.

Generic platforms often force one tree. Everything hangs off a single hierarchy, and the customer is told to "keep it simple". The result is either a structure that satisfies finance but confuses managers, or one that satisfies managers but makes consolidated reporting a spreadsheet exercise. Ask instead whether the system separates legal entities, organisational units, positions and grades, whether a position can carry more than one reporting line, and whether a reorganisation can be dated and applied in advance rather than keyed in on the day.

Giza Cable Industries, a cable manufacturer in Giza with more than a thousand employees and production lines running from low voltage to extra-high voltage across several plants, runs attendance, payroll and personnel on Orgarise. A structure like that only works when plants, shifts and positions are modelled as they exist on the ground, because attendance rules and pay rules attach to them.

Appraisal sheets and letter templates: where HR's own judgement lives

The third and fourth areas are less visible to IT but central to HR. An appraisal sheet encodes what the company believes about performance: which competencies matter, whether targets are weighted, whether a factory operator and a sales manager are assessed on the same form, and whether a self-assessment precedes the manager's rating. A global template with five generic competencies and a 1-to-5 scale flattens all of that.

Letter templates carry the same weight in a different way. An HR letter to a bank, an embassy or a government office in Egypt or Saudi Arabia must follow the wording, language and signature block the receiving party expects, and an experience certificate has to reflect what the law requires. If templates are hard-coded, or only available in English, HR ends up producing letters in a word processor and the system becomes a lookup tool.

The test is simple. Can HR staff build a new appraisal sheet with their own sections, weights and scales, assign it to a population, and run a cycle, without a developer? Can they design a bilingual letter template that pulls the employee's data and is requested and delivered through self-service? In Orgarise, the Performance module includes an appraisal sheet builder, evaluation cycles, development plans and succession planning, and letters and forms are built with the same designer approach in Arabic and English.

Where standardisation is right, and where it is not

None of this means every existing process deserves to survive. A useful rule is to separate what the process decides from how it is executed. The "what" (who has authority, what the policy allows, which document is legally required) is the company's business and should be preserved in the system as it is. The "how" (paper forms, a signature on three copies, an email to payroll) is usually an artefact of the old tools and should be standardised without hesitation.

Some concrete examples. Standardise the data captured on a leave request, the codes used for absence types, and the way an approval is recorded, because those benefit from being uniform. Do not standardise the approval route itself, because it reflects real authority. Standardise the format of an appraisal cycle calendar, but not the content of the sheet used for different job families. Standardise the storage and retention of contracts (Egypt's Labour Law 14/2025 requires Arabic contracts in four copies and five-year record retention), but not the wording of letters different authorities expect.

A second rule: standardise where the law already does. Working hour limits, overtime premiums, social insurance calculation and end-of-service awards are set by regulation in Egypt and Saudi Arabia, and a system that handles them correctly by default is a reason to stop maintaining local variants. Configurability is valuable for the parts of HR that are genuinely yours, not as a way to re-implement statutory rules by hand.

How to evaluate configurability in a demo

Vendors will always say their system is configurable. The word has no fixed meaning, so the demo has to establish what it means for them. Send three real processes in advance, in writing: your most complicated approval chain, your organisational structure with its awkward parts, and one appraisal sheet plus one letter template you use today. Ask the vendor to build them in the demo environment, and ask who did the building.

In the session, watch for four things. First, whether the configuration was done by a consultant on screen or by a developer offstage. Second, whether a change can be made live: add a level to the chain, rename a grade, add a weighted section to the sheet. Third, whether the Arabic version is produced by the same configuration or maintained separately. Fourth, what happens on upgrade: does the vendor state that configured objects survive version changes, and will they put that in the contract?

Then ask about ownership after go-live. Who in your team will be able to make the next change, how long the training takes, and whether the vendor's implementation timeline reflects configuration rather than coding. For mid-market deployments, Orgarise typically goes live in two to six weeks depending on modules and data, which is only possible when the process-specific parts are configured rather than built.

The takeaway: bring your three ugliest processes to the demo

The question is not whether HR software should adapt to your processes or you to it. It is which parts of your processes are worth preserving, and whether the system lets HR preserve them without writing code. Decide that before the demo, send the three processes that embarrass you most, and judge the system on how it handles them. A vendor who builds them in front of you has shown configurability. One who explains why you should not need them has told you what the next five years will look like.