Chaos under control. No surprises.

A CMDB nobody trusts

Data goes stale, people keep their own spreadsheets and ask colleagues during incidents.

Impact discovered after the outage

Whoever plans a change often does not know which services it will hit.

Approvals lost in email

Outages, requests and prices are approved in different channels and nobody knows what is pending where.

Patching as a monthly negotiation

Every window is negotiated again and critical vulnerabilities wait.

Thousands of alerts, no situation

Monitoring reports symptoms, not causes. People stop reading.

Costs not linked to services

Cloud and data centre invoices cannot be attributed to services or customers.

CMDB and dependency map

• 36 classes: services, applications, databases, VMs (VMware, Hyper-V, Azure Stack Hub, OpenShift Virtualization, public clouds), IBM Power (LPAR, VIOS), physical servers, containers, storage, SAN, network, OT
• Discovery API with matching, full sync and retirement; CSV and Excel import, manual creation
• Versions and history of every change: who, when, what and from where
• Data quality and inconsistency checks
• Layered dependency map with item neighbourhood and grouping by class; impact and root-cause items always on top
• Outage simulation and single points of failure
• Redundancy-aware impact: clusters, HADR, Data Guard, PowerHA, HyperSwap
• Inventory of OS, software, disks and network cards; OS, software and hardware lifecycle
• OpenShift inventory import down to the physical layer: nodes, OpenShift Virtualization VMs, hosted clusters, network and ODF

VMware virtual network and disks

• Distributed and standard virtual switches, port groups and VLANs
• Virtual machines and VMkernel adapters linked to port groups
• Host uplinks to leaf switches – impact from the virtual to the physical network
• VM disks in the server inventory; a shared or RDM disk as its own item
• Disks linked to datastores automatically during discovery
• “Disks and storage” data quality check

Incidents and requests

• The affected service, impact and resolver team are suggested from the CMDB item
• Priority from impact and urgency, major incidents with a review and corrective actions
• Parent incident for a mass outage; child incidents close with it
• Request catalogue with forms, approval, due dates and fulfilment steps
• A request that changes infrastructure continues as a change
• Configurable workflow: states, transitions and permissions

SLAs and business hours

• Response and resolution SLAs in business hours with calendars and holidays
• Pause, service, customer and default SLAs
• Monthly SLA performance and warnings before a breach
• Measured service availability against the SLA target

Problems and known errors

• A problem from an incident, a major incident review or a post-change review
• Problem suggestions from recurring incidents on the same item
• Root-cause analysis, workaround and a known error record
• The incident resolver sees the known error and its workaround
• Fix through a change, closure only after verification

Changes and maintenance windows

• Standard, normal and emergency change models with steps and lead time
• Impact calculated before submission
• Slots only inside maintenance windows, outside freezes and collisions
• Rolling execution item by item
• Outage approval by the service owner, change manager, CAB
• Approval level by risk from a questionnaire, minimum number of approvers
• Separation of duties: neither requester nor implementer approves their own change; delegations with an audit trail
• Closure with an outcome and a post-change review
• CMDB edits only with a change, including rack placement or part replacement
• Change calendar and a filterable overview of maintenance windows

One approvals queue

• Outages, requests, price proposals and patch agreements in one place
• One ownership rule, fallback approver
• Every rejection with a reason

Event management

• Ingest from Zabbix, Prometheus/Alertmanager, Checkmk, Grafana and an API
• Deduplication, flapping, filtering and suppression during changes
• Situations by CMDB topology with a probable cause
• Incident from a situation in one step or automatically
• Live event stream, optionally via Kafka

Patch and vulnerability management

• Scanner findings import, vulnerabilities by server and service
• Actively exploited vulnerabilities and deadlines by severity
• Patch agreement: standing window, pre-approved patching, expedited mode
• Wave plans and changes from the plan in one step

Data centres and contracts

• Site, data centre, room, aisle, rack and rack unit with visualisation
• Service contracts, item coverage, expiry dates and vendor SLAs
• Incident escalation to the vendor according to the contract

AI assistant

• Incident drafts from situations and similar incidents
• Draft customer communication
• Change review before approval
• Optionally an on-premise model. A person always decides.

Procurement and IT asset management

• Asset cards linked to the CMDB, handover protocols and cost centres
• Accounting and tax depreciation, disposal through a disposal committee
• Purchase request → approval by the cost-centre owner, and by finance above a limit → order → receipt
• Supplier invoices with order – receipt – invoice matching
• Spare-part stores at data centres: minimum levels, transfers, issue against an incident or change, RMA
• Software licences: entitlements, assignments and compliance with installations in the CMDB

Costs, billing and price list

• FOCUS cost import, currency conversion at the CNB rate
• Costs by customer, project and business service
• Pivot tables and monthly billing data
• Service price list and server calculator; price changes approved by the service owner
• Application capacity model: users, peak load and tiers

Customer separation

• A customer’s users see only their own data, including costs
• Roles scoped to a customer, team or item
• Sync with a primary CMDB (ServiceNow, SMAX) via external IDs

Adoption roadmap and rollout governance

• Discovery workshop wizard: goals with KPIs, area maturity, data availability, profile and modules
• Priorities by impact and effort, rollout waves respecting dependencies and capacity
• Workstreams per module with tasks, owners, milestones and readiness checks
• Approved baseline, slippage with reasons and go / no-go steering committee decisions
• KPIs measured by Stilla every week and a steering committee report

Governance, security and audit

• 14 scoped roles, a RACI matrix checked against permissions
• SSO and API tokens for service accounts
• Five-year audit trail, before and after state for configuration
• Email and Slack notifications by rules and templates
• Deployed as SaaS or a container on OpenShift; works on mobile too