Incidents and Improvements

• Incidents and Improvements
  • Incident reporting & configuration
  • Incident investigation & data collection
  • Incident evaluation & tracking
  • Non-Conformities (Findings)
  • Action Plans & Change Control

Incident reporting & configuration

ZYGHT supports a two-stage reporting flow that begins with an Immediate/Flash Report and advances to a Preliminary Report, with administrators able to tailor module labels (e.g., Incident types, Levels, Methodologies) and enable features such as role verification and flash notifications. Administrators configure Flash Report notification rules by recipient scope (full user list, work area, site/project, org chart) and by where the incident was reported; rules can be bulk managed. This ensures critical details are captured early and routed to the right people while keeping terminology aligned to local processes.

Incident investigation & data collection

After classification and association in the Preliminary Report, teams select an investigation methodology (e.g., Five Whys, ICAM) and proceed through a structured workflow: define the leader and deadline, conduct the investigation, and record findings with evidence. Administrators can enable “Data Collection” for chosen methodologies and configure investigation background subcategories as data-collection types, allowing investigators to add, edit, restore, and version specific records with full history and PDFs. This configuration centralizes evidence capture and drives consistent, auditable analyses across methodologies.

Incident evaluation & tracking

ZYGHT lets users evaluate the incident’s impact level using a risk matrix. Depending on configuration, evaluators can apply a generic matrix or select scoped matrices (e.g., environmental, financial, reputational); the highest resulting level is stored and displayed on lists and PDFs. Managers can also track how long each incident remains in a given state and review a detailed state-change history, including dates, durations, and the user who performed each change or reset—supporting SLA oversight and process compliance.

Non-Conformities (Findings)

The Non-Conformities area governs closing, verifying, rejecting, and deactivating findings with role-based levels: Level 1 reports, Level 2 closes, and Level 3 verifies. Admins can require activities for palliative closures and allow attachments (e.g., up to five images) to strengthen evidence in reports. Web and mobile flows include My Tasks/My Findings, thermometer indicators, and justification on approval or rejection; visibility and assignment depend on org-unit linkage, roles/levels, and, when enabled, contractor-company data-visibility restrictions. Together these controls create a clear, auditable path from observation to verified closure.

Action Plans & Change Control

Action Plans translate corrective actions—often arising from incidents or preventive controls—into scheduled activities with responsible and validation roles, tracking, verification, and mass-edit tools. Users can create plans from incidents or mobile app reports; progress updates automatically on approval, and rejected work prompts rescheduling. The Change Control module governs operational changes via registered requests, preliminary risk assessments, committee evaluation, final approval, and app-based execution with additional controls/checklists as needed. These capabilities operationalize continuous improvement by tying corrective actions and change governance to clear workflows, roles, and evidence.