OT System Engineer

1\. ROLE

OT System Engineer — Infrastructure Tower / Application Tower.

One role, one grade, two technical specialisations. The core of this job description applies to both towers. The tower\-specific technical domains are set out in Annex A (Infrastructure) and Annex B (Application). A candidate is expected to be strong in the domains of at least one annex and to have — or be willing to build — a working knowledge of the other.

2\. PURPOSE

As an OT System Engineer within the OT Operations team, you keep our clients' manufacturing IT environments running securely, reliably and efficiently — and you make them measurably better. Our scope sits at Purdue Levels 2 to 3\.5\.

You work either on the infrastructure layer (networks and segmentation, virtualization, operating systems, monitoring, backup, hardware) or on the application layer (MES, historians, databases, interfaces and integrations). Whichever your primary tower, you are expected to understand enough of the other to follow a problem across the boundary instead of handing it off.

You engage directly with clients to identify what they actually need, and translate their operational requirements into stable, scalable and well\-documented implementations under the guidance of your Team Lead.

3\. DIMENSIONS OF THE JOB

• You ensure operations run according to defined procedures, agreed service levels and planning, maintaining stability, reliability and security across client environments.


• You are accountable for the outcome of your assigned tasks within a defined scope, and you contribute proactively to process improvement rather than only responding to incidents.


• You own the operational and security side of the estate: run, support, patch, harden, monitor, back up, integrate, document and improve.


• You are assigned a primary tower by your Team Lead, and may be deployed across both towers as client demand and your skill profile allow.


• You escalate to Technical Leads and Subject Matter Experts when a problem exceeds your scope, with a clear and complete handover.


• The service is delivered on a rotating shift and on\-call model. This is a structural condition of the role, not an occasional extra — see section 6\.

4\.1 Operational Service Delivery

Aim: *Maintain system availability, operational stability and compliance within agreed service levels.*

• Provide second\-line support for the systems in your scope — incidents, requests and changes — following ITIL\-based incident, request and change management.


• Work within the agreed SLA: respect priorities, response and resolution targets, escalation paths and communication rules towards the client.


• Perform proactive maintenance: patching and vulnerability mitigation, hardening, health checks, backup and restore verification.


• Register your time and ticket updates accurately and on time — service reporting and SLA evidence depend on it.

Aim: *Resolve problems at the cause, not only at the symptom — including problems that cross the infrastructure / application boundary.*

• Diagnose systematically: reproduce, isolate, form and test hypotheses, and record what has been ruled out.


• Trace a transaction or data point end to end across the estate — from the shop\-floor source, through interfaces and integration layers, into databases, applications and reports — to locate exactly where it breaks.


• Read and interpret logs, interface traces, database queries and monitoring data in the context of the client's production process.


• Contribute to problem management and root cause analysis, and convert findings into permanent fixes or properly documented workarounds.


• Place your analysis correctly within the reference architectures we work in (ISA\-95, Purdue model) so that scope, level and ownership are unambiguous.

Aim: *Reduce repetitive and reactive work through automation and structural improvement.*

• Write and maintain scripts and queries (e.g. PowerShell, Python, SQL, Bash) to automate operational, verification and reporting tasks.


• Use and configure automation and configuration\-management tooling (e.g. SCCM, Ansible, Puppet, scheduled jobs, deployment pipelines).


• Identify recurring incidents and manual routines, and propose the change that removes them at the source.


• Bring improvement proposals forward on your own initiative. Being permanently in firefighting mode is treated as a problem to be solved, not as a normal state of the service.

Aim: *Deliver solutions that fit the client's operational reality.*

• Engage directly with client users, key users and IT/OT counterparts to understand requirements, constraints and priorities.


• Translate operational needs into technical specifications and realistic options, including the impact on availability and on production.


• Implement changes together with colleagues in a secure, scalable and standardised way, respecting change windows and production risk.


• Communicate technical findings in terms of what they mean for the client's operation, not only in technical terms.

Aim: *Make knowledge reusable so that the service does not depend on individuals.*

• Keep documentation of configurations, interfaces, procedures and known issues clear, current and findable.


• Write up resolved problems so that the next engineer solves them faster.


• Share knowledge actively with peers — including across the tower boundary — and contribute to standardisation and to the team knowledge base.


• Keep asset and skill inventories accurate, and contribute to the onboarding of new colleagues.

Aim: *Timely completion of assigned work within team priorities and planning.*

• Execute tasks assigned by the Team Lead, respecting priorities and timelines.


• Signal risks, blockers and expected delays early, rather than at the deadline.


• Apply best practices, operational standards and the quality system throughout execution.

Knowledge and experience

• Diploma — at least a professional bachelor's degree in a technical subject (Computer Science, IT, Industrial IT, Electronics or Automation) and/or a demonstrable affinity with software development.


• Core technical baseline (required for both towers) — Windows Server and client administration; basic Linux/Unix; virtualization; TCP/IP networking fundamentals; relational databases and SQL; scripting; monitoring concepts; backup and restore concepts; the ISA\-95 / Purdue reference model.


• Tower\-specific depth — demonstrated strength in the technical domains of at least one tower (Annex A or Annex B), with a working knowledge of the other and the willingness to grow into it.


• Experience — minimum 2 years in a system engineering, infrastructure, application support or industrial IT role. For the Application Tower profile, at least 3 years of hands\-on database and interface work is preferred, given the depth of SQL required.


• Industrial context — experience in a production, process or manufacturing environment is a strong advantage. Understanding that downtime has a direct and immediate cost is essential.


• Running\-in period — one to two months to learn the organisation's way of working and processes and to start contributing on a project; six to nine months to work independently, through on\-the\-job training.


• Languages — English, spoken and written. Proficiency in local or additional languages is an advantage in our international environment.

• Structural thinking — breaks a problem into its parts, reasons about systems and dependencies rather than symptoms, and works from evidence.


• Proactive drive — improves things before being asked; does not settle into a purely reactive routine.


• Results\-driven — delivers reliably on assigned tasks and aligns with the planning.


• Problem\-solving — provides a practical short\-term solution and follows it with a structural fix.


• Functional expertise — understands the tools, platforms and procedures relevant to the assigned tower.


• Accuracy — precision in documentation, configuration, patching, queries and diagnostics.


• Information handling — organises and prioritises technical information systematically.


• Collaboration — communicates clearly in a remote, distributed and multicultural environment.


• Ownership — follows a case through to closure, including the documentation and the client feedback loop.


• Learning agility — willing and able to cross the tower boundary and to pick up unfamiliar platforms.

• Availability for travel to client sites.


• Flexible working hours, including planned work outside production hours during change windows.


• Participation in the rotating shift schedule and the on\-call rota — set out in full in section 6\.


• Acting in line with the quality system and with client site safety and security rules.

OT Operations delivers a continuously available service. Working in a rotating shift schedule and taking part in the on\-call rota are core conditions of this role, and apply to both towers.

6\.1 How coverage is organised today

• Active shifts — Monday to Friday coverage is delivered by two rotating shifts, Morning and Afternoon. You rotate through them according to a published rota. Indicative windows are approximately 07:00–15:00 and 15:00–23:00; exact times and the reference time zone are confirmed per country, contract and client site.


• Nights — covered by an on\-call (standby) rota rather than an active shift. While on call you must be reachable and able to connect and work within the agreed response time.


• **Weekends

Este anúncio é de Indeed. Ver anúncio original ↗