The Challenge: Disparate Systems, One Broken Process
A top-five IT consultancy operating across multiple cities had a problem that most large enterprises eventually face: years of facility expansion had produced a patchwork of physical access control infrastructure. Different campuses had been built at different times, procured by different facility management teams, and equipped with whichever Door Access Control System (DACS) vendor had won that particular tender. The result was a mix of Kantech and IDTeck hardware across twelve cities, with additional legacy systems at older campuses.
Each DACS brand spoke its own protocol. Each stored access logs in its own proprietary format. Extracting attendance data from these systems required manual exports, format conversions, and city-by-city reconciliation by HR staff at each location. The normalised data then had to be pushed into SAP HCM for payroll and leave management — a process that involved additional manual handling at the central HR level.
End to end, processing attendance for 40,000+ employees took several hours every day. This was not a one-time project bottleneck. It was a daily operational cost, every working day, consuming significant HR capacity and introducing a window of uncertainty: payroll was always running on yesterday's data, at best.
Beyond attendance, the security operations team had its own version of the same problem. Monitoring access control events, surveillance cameras, and fire protection alarms across twelve cities meant logging into multiple vendor-specific consoles. Correlating a security event with a surveillance feed required manual coordination between operators at different consoles. There was no unified picture of the estate.
The Integration Architecture: Normalise, Apply Policy, Post
The Teamnet integration platform connects to each DACS brand through its native SDK — Kantech's SDK for those campuses, IDTeck's StarWatch interfaces for others. This matters because it means the platform reads live, authoritative data directly from the access control system rather than relying on scheduled exports or file drops, which introduce timing gaps and potential data loss.
Once raw access events are ingested, the platform applies a normalisation layer that maps each vendor's event format to a common schema. A swipe-in event from a Kantech reader and a corresponding event from an IDTeck terminal become identical records in the attendance engine. From that point, the processing logic is agnostic to hardware vendor.
The attendance engine then applies the organisation's policy layer. This is where the real complexity lives:
- Shift rules: Which shift does a given employee belong to, and does the entry time constitute a late mark under the applicable grace period?
- Half-day logic: When does an early departure trigger a half-day deduction versus a regularisation request?
- Overtime calculation: Which employee categories are eligible for OT, and what are the thresholds by day type?
- Leave interaction: If an employee has an approved half-day leave in SAP, the attendance engine reconciles the access log accordingly before finalising the record.
The finalised attendance record is then posted directly to SAP HCM via the standard integration interface. The entire pipeline — from DACS ingestion to SAP update — completes in under fifteen minutes for the full 40,000-employee population. What previously required hours of manual work across twelve cities now runs automatically, every morning, before the working day begins.
The Security Console: One View Across the Estate
The same integration platform that processes attendance also underpins the unified security operations console. This was a natural extension of the architecture: if the platform already maintains live connections to every DACS in every city, those connections can carry security events as well as attendance records.
The security console gives operations teams a single interface showing real-time access control events, surveillance camera feeds, and fire protection alarms across all facilities. When an access control event triggers — an unusual entry pattern, a tailgating alert, an out-of-hours access attempt — the operator can immediately pull up the corresponding surveillance footage from the same console without switching applications or calling a remote colleague.
The security team went from managing four separate vendor consoles to a single view of the entire estate. Event correlation that used to take minutes of cross-referencing now happens in seconds.
Customised reports are generated automatically for the security function — daily access summaries, anomaly reports, contractor movement logs — all configured within the platform's report builder and delivered on schedule without manual intervention.
Fourteen Years in Production
The deployment metric that matters most for enterprise integration platforms is not performance at go-live. It is longevity. Integration platforms sit at the intersection of multiple systems, each of which evolves independently. A platform that requires replacement every time a DACS vendor releases a new hardware generation, or every time SAP is upgraded, or every time the organisation changes its shift policy, is not an asset — it is a dependency.
This deployment has been in continuous production for over fourteen years. During that time it has absorbed:
- New campus additions with different DACS hardware brands, integrated without architectural changes
- Multiple rounds of policy evolution as the organisation's HR practices matured
- SAP version upgrades, with the integration interface adapting to updated API specifications
- Expansion of the security console to cover additional facility types and alarm categories
The architecture's durability comes from a deliberate separation of concerns: the hardware adapters are modular and vendor-specific, the normalisation layer is stable, and the policy and reporting layers are configurable without code changes. Adding a new DACS brand means building a new adapter, not rewriting the system. Changing a shift policy means updating configuration, not opening a ticket with the development team.
For large, geographically distributed organisations with mixed infrastructure, the integration challenge is not a project to be completed — it is an ongoing operational reality. The right architecture treats it as such from day one.