Docs

Modules

What each module does, grouped by area of the application.

Services Monitoring Service desk Changes Configuration Finance and assets Administration

Services

service portfolio, service levels and request catalogue

Configuration database

General infrastructure model: IBM Power (LPAR, VIOS, HMC), virtualisation VMware, Hyper-V, and Azure Stack Hub, virtual servers in public clouds (Azure, AWS, GCP), container clusters anywhere (OpenShift and HyperShift, AKS, EKS, GKE), applications, application platforms, and databases, disk arrays, SAN, and network (routers, L3/L2 switches, port aggregation LACP and vPC, VLANs, subnets, routing). For LPARs, you'll see the path to data through NPIV, SAN, and zone to the disk array. On-prem infrastructure costs are calculated directly from the CMDB. The dependency map displays items from business service down as a graph or tree, with a filter by customer and environment. Impact analysis simulates the outage of a selected item and shows affected services, applications, and customers; for redundant elements (pairs of switches, cluster nodes, SAN fabrics A/B), it distinguishes between outage and degradation. For business services, applications, platforms, and databases, the High Availability card simulates the outage of each supporting item, lists single points of failure, and shows redundant groups (application cluster, Db2 HADR, Oracle Data Guard, PowerHA, VIOS pairs, HyperSwap volumes). Each item has an icon by type (physical server, VM, LPAR, application, database, disk array, tape library, SAN switch, router, firewall, L2/L3 switch…), icon colour corresponds to category; an icon overview is below in help. For hypervisors, VIOS, and LPARs, there is a Storage Path card across both SAN fabrics. Relationships show redundant groups and relationships whose failure means only degradation (e.g., array management network, tape library). The 'is backed up by' relationship shows which backup platform protects the item. On the phone, the map opens as a tree; the graph can be scrolled with a finger and zoomed with two fingers. Each item has an owning team; for hardware, you can see the installation date, warranty end, and manufacturer support end. The location of VMs and partitions (host, cluster, Power server) is changed only by discovery from the management tool of the given virtualisation (vCenter, SCVMM, Azure Stack Hub, cloud API, HMC). From the item detail, you can directly report an incident or schedule a change.

SLA

Service Level Management (Services → SLA). SLA fulfilment: ratio of incidents with response and resolution within the deadline by months and according to SLA agreement, priorities, services, customers, or teams, comparison with the target, list of violations, and fulfilment of request deadlines. SLA agreements (default Gold, Silver, Bronze, Standard): response and resolution targets for P1–P4, working hours (can be overridden for priority, e.g. P1 24/7), required fulfilment in %, target availability, and when to notify (after expiry of % of deadline). You assign an agreement to a business service or customer; SLA of service applies → SLA of customer → default SLA. Working hours: weekly windows by days, Czech public holidays (including Good Friday and Easter Monday), and other free days, 14-day preview. SLA time runs only in working hours and is not consumed when an incident is on hold. Request deadlines: deadline for fulfilling each catalogue item in hours and working hours. Changes apply to new incidents and requests; open incidents can be recalculated with a button. Edited by incident manager and platform administrator (sla.manage).

Request management

The service catalogue contains standard requests (new server, capacity extension, firewall rule, access, restore from backup, namespace in OpenShift). Each item has a form, an approval method (no approval, customer's service owner, resolver team lead, change manager), a deadline, a resolver team and fulfilment steps. A request without approval goes straight to fulfilment. The resolver takes over the request, ticks off the steps and marks it as fulfilled; the requester closes it. An item whose fulfilment changes infrastructure is linked to a change model – a change is created from the request, and the request can be fulfilled only after the change is completed. The catalogue is managed by the configuration manager in the Catalogue Management tab. For an item linked to a standard change model the application creates the change itself and schedules it for the first free slot without further approval. The Changes card in the detail shows linked changes and the requester is notified when they are scheduled, started and completed. A request that is really a fault is converted by the resolver with Convert to incident.

Monitoring

monitoring events, their correlation and rules

Event management

Receiving events from monitoring (Zabbix, Prometheus/Alertmanager, Checkmk, Grafana, Dynatrace, generic API) and reducing them to what the operator needs to react to. Each event is paired with a configuration item (host name, FQDN, IP, serial number or ci_id tag) and the affected business service, customer and ownership team are filled in from the CMDB. Filtering rules discard noise, suppression rules and ongoing changes on an item suppress the alert (do not wake the operator). Repeated events of the same problem (same fingerprint) only increase the alert counter; an OK message resolves the alert, without it, it is resolved after silence. A fluctuating alert (multiple state changes per window) is marked as flapping. Alerts are merged into situations: topologically according to an outage simulation in the CMDB – only an item whose outage really explains the alert can be its cause (so one switch of a pair is not the cause of a server outage), and among several candidates the one explaining the most alerts wins (★). Alerts explained by the cause are symptoms: visible in the situation, without notifications, excluded from noise metrics and resolved together with the cause. When several items alert and share a silent common carrier (e.g. VMs on one host), one situation with an inferred cause is created. Further grouping is by service and time and by related change. The console ranks situations by criticality of the affected service and severity and updates live; the operator confirms situations, assigns them to a team, mutes them for a time with a reason, merges and splits them. An incident from a situation is pre-filled (item, service, impact from the real impact on the service – outage, degradation or only loss of redundancy – and its criticality, urgency from severity, team, alert timeline, link to change) and alerts remain linked to the incident – new situation alerts are added, resolving all alerts suggests resolving the incident and a returning problem reopens the incident. An automatic incident rule creates an incident without an operator. Noise compression shows a funnel of events → alerts → situations → incidents, checks that never led to an incident (trigger tuning suggestions), and hosts without an item in the CMDB. With demo data, events can be simulated (hypervisor failure, slow database, flapping, noise). The pilot variant processes events directly in the application; for large volumes, processing is moved to Kafka and Flink (see README).

Service desk

incidents, problems and request fulfilment

Incident management

An incident is an unplanned interruption or degradation of a service. When creating an incident, you select the CI where the problem occurs – the application will calculate which services are impacted, suggest the impacted service, impact, and resolver team (CI ownership team). Priority P1–P4 is based on impact and urgency; response and resolution terms are defined by the SLA of the impacted service (or customer, or default) during its working hours – the form will show valid SLA and deadline in advance. Statuses and transitions are defined by workflow (Administration → Workflow), default: new → assigned → in progress → (on hold, awaiting vendor) → resolved → closed. Buttons in detail correspond to transitions you are allowed to make; some require a comment. Putting on hold shifts SLA deadlines. Resolution requires a code and description of the resolution; the reporter can reopen the incident. Incident manager declares a major incident. In the detail, there is an impact from CMDB, changes around incident opening (you can mark a change as a cause), and the Propose change and Emergency change buttons. Incidents for a CI are visible in the CI detail; monitoring can create them via API. The Changes card shows the changes that resolve the incident – one change can be linked to several incidents and an existing change can be linked to the incident; the reporter is notified when the change is scheduled, started and completed. If it is not a fault but a service request, convert the incident with Convert to request: choose a catalogue item, the reporter becomes the requester and the incident is cancelled with a link to the new request.

War room

Coordination of a major incident (P1/P2). Open the war room from the incident detail. The application proposes the team line-up from data – core and backup based on alerts, candidate changes, the supporting chain in the CMDB and similar incidents – and compares it with a “wide bridge”. It tracks attendance and cost by team hourly rates and hypotheses (ruled-out area → suggestion to release a team), and on closing writes a summary to the incident work log.

Problem management

A problem is the cause of recurring or major incidents. It is raised from an incident, from a major incident review, from a post-change review or by the daily check for recurring incidents (count and period are set in Process parameters). The cause becomes a known error with a workaround that resolvers see on further incidents. The permanent fix is made by a change raised directly from the problem or linked to it (Changes card). When the change completes successfully, a problem with a documented root cause moves to Resolved on its own; a failed change returns it to analysis; close the problem once the fix is verified. A problem raised from a parent incident also takes over its child incidents.

Changes

changes, approvals and patching

Change management

Changes are created from change models. The model determines the change type (pre-approved standard, normal, emergency), who approves (owner of the affected service, change manager, CAB, or nobody for a standard change), whether the date must fall within maintenance windows, the required lead time in days, whether the change can be implemented gradually item by item, whether it may run during a change freeze, which item classes it is intended for and what steps the change has. Procedure: select a model, then a business service and the items in its tree (or the items directly). The application calculates from the CMDB which services and applications will be down and which only degraded, finds dates according to the model rules (maintenance windows, freezes, collisions with other changes, lead time) and creates the approvals after submission. For downtime, the business service owner approves (A) and application owners are consulted (C). The implementer starts the approved change, ticks off the steps and completes it – it can be completed only after all steps are done. A change for an incident (including an emergency one) is created directly from the incident detail, a fix change from the problem detail; a standard change for a catalogue request is created by the application itself. Change models are managed by the change manager in the Change models tab, maintenance windows by service owners in the Maintenance windows tab. The Addressed records card shows the incidents, problems and requests the change resolves; link more by record number (the link the change originated from cannot be removed). When the change is scheduled, started and finished, reporters of linked incidents and requesters of linked requests are notified. The outcome propagates to linked records: a problem with a documented root cause moves to Resolved, a failed change returns it to analysis, incidents and requests get a log entry with the next step. For 24 h after completion the application watches alerts on the change items – if any appear, the post-implementation review is required. From a change that is in progress or failed, completed with issues or with alerts after completion, the Create incident button opens an incident that records the change as its cause.

Patch management

Server vulnerabilities, patch agreements with service owners and a change coordinator assistant for the patching plan: it calculates affected services from the CMDB and proposes slots in their maintenance windows, outside freezes and collisions with other changes; service owners approve the outage. Vulnerabilities of an item are also shown on its CMDB card.

Configuration

CMDB, data centres and enterprise architecture

Data centres

Data centre overview (indicators, halls, what needs attention), hall floor plan and rack with hardware placement from the CMDB. Inserting or moving a physical device creates a change or a request; planned positions are shown in the rack as an outline.

Settings

Database: production data or separate demo data (applies to the whole application, written to the audit trail); in demo mode, users with Czech see the Czech demo and users with English the English demo. Retention: the audit trail is kept for 5 years and the database will not allow a record to be deleted earlier or changed; history of CIs and relationships according to settings (default 5 years), discovery and connection runs for 13 months. Teams: owners of CIs, services and changes, and resolvers of incidents and requests, with members and lead. CMDB data quality: inconsistencies (VM location, missing ownership team, class detail, costs) and sources of truth about location. HW lifecycle: end of sale and support of models. CNB exchange rates for converting costs in foreign currency.

Enterprise architecture

An ArchiMate model: capabilities, actors, processes, applications and application services, data objects and technology linked to the CMDB. Applications are assessed by TIME (Tolerate, Invest, Migrate, Eliminate) and lifecycle phase; the target state is described by plateaus and work packages linked to changes. The artefact detail shows costs, availability, incidents, changes and the chain down to infrastructure. Export in Open Exchange format.

Finance and assets

costs, billing, assets, purchasing and contracts

Cost Overview

Monthly costs of all customers or a selected one. Tiles show costs, allocated compute, its utilisation, memory, and storage. The graph is for the last 12 months; clicking on a column changes the month. Clicking on a customer row narrows the whole page to that customer. The Download FOCUS CSV button outputs rows in FOCUS standard.

Cost analysis

Custom data views: you can select up to 4 dimensions (customer, project, cluster, item…) for rows, one for columns (typically month), and choose measures and filters. The table recalculates immediately. A saved table is available to all users; Export CSV opens in Excel (semicolon separator).

Billing

Monthly templates for invoicing. In the Templates tab, you set row grouping, surcharge, discount, and VAT; in Invoice data, you set customer IČO, address, and contract. You generate templates for the whole month at once; a draft can be regenerated, an approved template is frozen. Status: draft → approved → sent, cancellation is possible anytime.

Price List

Finance → Service price list. Price list versions (draft, valid, archive) with unit prices by section: infrastructure, virtual machines by platform (VMware vSphere, Azure Stack Hub, OpenShift Virtualization – vCPU, memory, disk), operating systems (Windows Server, RHEL, SUSE, Ubuntu), standard Windows and Linux servers, support levels and operational services, request fulfilment (link to the catalogue) and change implementation (change type, change model). Prices are edited by a role with the rate.manage permission; the virtual server calculator compares platforms. Each cost line carries a reference to the price list version, so it is always traceable which price it was valued at.

Asset register

Asset records linked to configuration items: purchase, receipt, invoices, putting into use, depreciation, cost centres, spare-part stores and handover protocols. A closed hardware installation change puts the record into use; disposal respects posted depreciation.

Software licences

Entitlements from licence agreements by vendor and product, assignment of licences to servers, databases and users, and compliance with installations found in the CMDB. Consumption is the greater of assigned licences and discovered installations; consumption above entitlement is highlighted.

Vendors and service contracts

Finance → Suppliers and contracts (service contracts and suppliers). A supplier has a hotline, support portal, customer number and contacts with escalation level (hotline, 1st and 2nd escalation, management). A contract (support, maintenance, subscription or extended warranty) has a term, notice period, automatic renewal, advance notice days, price and invoicing, customer and contract administrator. Support levels are the supplier's SLAs: supplier working hours, response and repair time, on-site technician. Covered devices are contract lines – CMDB items with their own level, serial number, period and optionally price (otherwise the contract price is apportioned). Documents (contracts, amendments, terms, max. 10 MB) are stored in the database. Expiry is checked daily: notice to the contract administrator, the team and the Contract administrator role at the first threshold crossed, a “terminated” message after the end, and automatically renewed contracts are extended. In an incident, the Supplier card finds valid support for the item or the hardware it runs on; Report to supplier (or the transition to Waiting for supplier) starts the supplier deadlines, Supplier responded / Fixed closes them. The contract overview shows expiring contracts with the last notice day, hardware support coverage, hardware without support, annual costs by supplier and customer and supplier SLA fulfilment. Managed by the contract administrator (contract.manage); the incident manager and configuration manager can also read (contract.read).

Administration

integrations, people and access, application settings

Connections

Tenants and accounts from which data is collected: Azure, Azure Stack Hub, AWS, Google Cloud, Oracle Cloud, OpenShift, and data centre. Only identifiers and references to the vault (kv://, vault://…) are stored, never passwords or keys – the application refuses to store them.

Import and API

Loading FOCUS files (CSV/JSON) and REST API documentation for collection scripts, monitoring (incidents), and integrations. Repeated import of the same source for the same month replaces previous data, does not duplicate it. Foreign currency rows are converted to CZK using the CNB exchange rate on the first day of the period. Entries require an administrator or API token.

Notifications

Email messages (Resend or SendGrid) and Slack messages (incoming webhook to a channel). Rule = record (incident, request, change, CI) + event (creation, status change, assignment, comment, approval request, decision, impending and breached SLAs) + conditions (priority, major incident, target status) + template + channels + recipients (resolver, resolver team, reporter, requester, approvers, owning team, role holders, team, user, arbitrary address). The template has a subject and text in a rich text editor (bold, headings, lists, quotes, links, HTML source) and parameters {{incident.id}}, {{incident.priority_name}}, {{transition.to}}… inserted with a button from the right panel; values are filled from the record and escaped. Preview shows email and Slack using sample data or a selected record; test sending verifies the channel. A channel holds only a reference to a secret Worker (env:RESEND_API_KEY, env:SLACK_WEBHOOK_PROVOZ…), the application does not store keys or webhooks. SLAs are checked every 5 minutes (notifications 30 minutes before deadline and after it is breached, each only once). With demo data, messages in the default state are only logged, addresses in test domains (.example) are never delivered. The Sent tab shows a delivery log including errors and skipped messages.

Access and responsibilities

IT personnel roles (platform administrator, configuration manager, service owner, application owner, infrastructure specialist, change manager, incident manager, service desk, auditor, service discovery account) with scope for a customer, team (from team evidence), or specific item. RACI matrix determines who performs, approves, consults, and is informed about configuration data and changes; the application ensures that R and A roles have corresponding permissions. Service accounts receive API tokens; audit trail records every entry.

Workflow

Statuses and transitions for incidents, requests, changes, and configuration items. Each status belongs to a system status, which underpins application logic (SLAs, approvals, change steps, CI retirement) – a custom status such as “Waiting on Vendor” behaves like Suspended and SLA time stands still. Transition matrix: row = initial status, column = target status; clicking on a cell adds or edits a transition. For a transition, you set the button label, permissions (evaluated within team, customer, or service scope), whether the reporter / requester / proposer can use it, whether it is an approval step (requests), mandatory comment and fields (resolution, resolver), and button appearance. Only the application can lead to approval pending, approved, and rejected statuses for changes (by sending deadline and approver decisions). System statuses cannot be deleted, only renamed; deactivate a custom status that some record uses. Configuration is shared for production and demo data. Edited by platform administrator and configuration manager (workflow.manage).

AI assistant

A language model helps wherever people work with text – it only ever proposes, a person decides. Situation summary (Event management): what is happening, the probable cause with the CMDB item, recommended steps and a confidence level; created automatically for situations from a configured severity, otherwise with a button. Incident pre-fill: when creating an incident from a situation, the “Suggest with AI” button; in Report incident, the “Describe the problem in your own words” field – the item, service and team are chosen only from the CMDB, and the priority is always calculated by the application from impact and urgency. What helped last time: similar resolved incidents by meaning of the text and advice from their resolution. Communication: a draft progress update for customers and a closing report – edit, copy or save as a comment, nothing is sent automatically. Change review: rule-based checks (description, rollback, risk vs. outage of a critical service, post-change verification, communication) and a summary for approvers. Personal data and secrets are masked before sending, every proposal is logged (Administration → AI assistant → Recent proposals) and the “Did this help?” rating measures quality. For customers with an “on-premises only” or “no AI” policy, no data is sent to the cloud model. Without a model, or once the daily limit is used up, a deterministic proposal is shown. Managed by the platform administrator (ai.manage): switches, limit, versioned prompts, customer policy.

Operational overview

Introduction screen for management. Tiles: business services in operation, services without a single point of failure, number of servers, servers with unsupported OS, changes for approval, and costs for the last month – each leads to detail. Below them, business service status (criticality, SLA, status, resilience, next downtime), Infrastructure (Power, virtualisation, cloud, containers, applications, network, SAN, backup, and each disk array with occupancy, number of volumes, HA and DR replication, and FC ports), Redundancy (servers on two network elements, SAN in both fabrics, LPAR on a pair of VIOS, production datastores on mirrored volumes, production servers with backup, services without SPOF), Lifecycle and patching, Changes and downtimes (including overdue changes and change freeze), Discovery and data quality, and Costs. On the phone, services are displayed as cards.