The factory Know-How Reference Guide.

The BowTie Portal's real USP goes beyond the method: the overall situational picture it creates for corporate steering. Individual risk models are combined into a shared management insight.

This turns BowTie from an analysis model into a decision-making tool: a situational picture spanning all risk areas, with clear prioritization, responsibilities, measure status and budget needs. Management, the board or the Risk Director immediately recognize where action is needed.

More: BowTie Risk Management Portal ↗

The BowTie Portal consolidates risks from different areas – technology, IT, processes, suppliers, organization and compliance – into a shared management situational picture. Functional, procedural, technical, organizational and supplier-related risks become visible together in one aggregated picture.

Management thus sees the overall risk at a glance – across business units, departments and company boundaries, in one shared view.

The particular advantage: risks become tangible – translated into cost, impact and concrete investment decisions. Threat level, consequence costs, measure costs and benefit perspective are calculated.

This makes it visible which resources are needed to effectively reduce material risks, and which measures deliver the highest contribution to risk reduction. Budgets for risk reduction are traceably justified.

Some risks can only be partially controlled with reasonable effort. The situational picture makes transparent which risks remain in the red zone despite measures – i.e. remain critical or existential.

This transparency is itself a management decision: the company consciously decides which residual risk to carry, and checks whether the overall risk position still matches its risk-bearing capacity.

The situational picture is the central management information for the top steering level. The board, executive committee, Risk Director and oversight bodies receive clear answers: which risks are material? Where to invest? How is the overall risk developing? When is action needed?

Management, risk manager, business unit leads, risk owners and the risk team all work within the same system – with visible responsibilities and traceable delegation.

The BowTie method is a visual method for structured risk analysis. It places threats on the left, the central risk event – the Top Event – in the middle, and possible consequences on the right.

Barriers are modeled between these areas: measures, controls or prepared responses that either prevent the risk from occurring or limit its consequences. The name comes from the shape of the model: fanned out left and right, bundled in the middle – like a bow tie.

More: BowTie Risk Management Portal ↗

A threat is a trigger or cause that can lead to the Top Event occurring. Threats sit on the left side of the BowTie model.

Examples include power outage, software failure, staff shortage, market change, supplier failure, regulatory change or human error.

Important: threats explain why a risk can occur. They do not yet describe the later consequences.

The Top Event is the central moment in the BowTie model: a threat has taken effect, control over a situation has been lost, and consequences can follow.

Examples: "control room goes down", "data loss occurs", "supply shortage arises", "critical plant stops" or "market position is lost".

On the left, what leads to the Top Event is evaluated. On the right, what consequences can result from it are evaluated.

A consequence is a possible outcome that can arise after the Top Event occurs. Consequences sit on the right side of the BowTie model.

Typical consequences include revenue loss, claims for damages, reputational harm, delays, additional costs, supply outage, loss of production capacity, quality problems, or regulatory sanctions.

Once the risk has already occurred, this side is about mitigation, correction, recovery and damage limitation.

A barrier is a measure, control or prepared response that makes a risk manageable. Barriers can inform, warn, prevent, mitigate, correct, replace or stop.

In the BowTie Portal, every barrier is managed as an operational task – with a responsible person, deadline, workflow status, cost, expected impact and approval. This turns risk analysis into concrete risk management.

Key takeaway: A barrier is only effective if it is functionally appropriate, organizationally owned and operationally tracked.

A preventive barrier acts on the left side of the BowTie model. It reduces the probability that a threat leads to the Top Event.

Examples: dual control, technical redundancy, access protection, maintenance plan, training, early-warning indicator, supplier audit or automatic plausibility check.

Preventive barriers serve to avoid or reduce risk before the central risk event occurs.

A reactive barrier acts on the right side of the BowTie model. It limits the consequences after the Top Event has occurred.

Examples: emergency plan, backup process, crisis communication, restart plan, insurance, backup supplier, technical switchover or a prepared fault clearance procedure.

Reactive barriers are part of risk mitigation: they cushion the consequence and shorten the time to recovery.

The risk value links the threat level with the possible economic consequences. It helps to compare risks and prioritize investment in barriers in a traceable way.

The basic question is: how do the plannable costs of prevention or mitigation compare to the possible costs if the risk occurs?

The threat level describes how relevant and probable a risk's threats currently are. It can change due to technology, market, organization, staffing, legislation, suppliers or external events.

In the BowTie Portal, the threat level is more than an assessment; it triggers a steering signal: When it rises, barriers can be prioritized, additional controls triggered, or escalations started.

Consequence costs are the financially evaluated impacts of a consequence. This includes direct costs such as repair, replacement, contractual penalties or production downtime, as well as indirect costs such as customer loss, reputational damage or additional management effort.

Consequence costs make it visible which consequences are really material and where reactive barriers make economic sense.

A barrier causes plannable costs: setup, operation, inspection, training, documentation or technical implementation. Against this stands its benefit: lower probability of occurrence, reduced impact, or faster recovery.

The BowTie Portal makes this trade-off transparent. Budgets can thus be deployed exactly where they deliver the greatest contribution to risk reduction.

The situational picture is the aggregated overall view of all modeled risks. It condenses individual risks into a management overview with risk values, threat levels, measure status, open barriers, warnings and priorities.

The situational picture answers the management question: where does the company stand, where is action needed, and how is the risk profile developing over time?

Risk-bearing capacity describes an organization's ability to absorb the financial, operational and reputational consequences of occurring risks without jeopardizing its existence or ability to act.

The situational picture makes aggregated risk values, warning thresholds and escalation needs visible. This allows management to recognize whether the overall risk position still matches the company's risk-bearing capacity.

A risk alert arises when defined threshold values are exceeded – for example, rising threat level, high consequence-cost impact, overdue barriers, or exceeded risk-bearing capacity.

Warning thresholds and escalations ensure that risk management becomes active: the system informs the responsible roles, starts workflows and makes decision needs visible in the situational picture.

The risk inventory systematically checks the risk situational picture for currency. It is carried out regularly or as needed – for example, when new legal requirements, new technology, changed organization, new market participants, new suppliers, new findings or changed staffing arise.

In the BowTie Portal, the risk inventory is a structured process: risks are reviewed, threats and consequences updated, barriers assessed, and cost-benefit decisions prepared.

The risk manager is commissioned by management with risk management for the company. They coordinate methodology, approach, risk team, data quality and situational picture.

Their task is to enable steering capability in risk management: management receives a reliable, current and decision-ready view of the risk situation.

The risk owner takes on the functional modeling responsibility for the risks assigned to them. They contribute the knowledge of their business unit and ensure that threats, consequences and barriers are described realistically.

Risk owners are decisive for the quality of risk management: good risk models emerge where methodology and subject-matter expertise come together.

The risk team consists of people delegated from the business into the risk management organization. It links central methodology with distributed expertise.

In the portal, the risk manager, risk owners, business unit leads and other stakeholders work in the same system – with clear roles, responsibilities, approvals and evidence.

Operational risk management means that risks are not only described and assessed, but actively managed through concrete measures.

In the BowTie Portal this happens through barriers managed as tasks. Every task has responsible parties, deadlines, status, costs, impact, approval and history. This turns risk analysis into an ongoing management process.

An Excel risk list often records risks as individual table rows. The BowTie model additionally shows the relationships: which threats drive the risk? Which consequences arise? Which barrier acts where? What costs and benefits are associated with them?

This produces traceable risk models instead of isolated entries. The results become evaluable, manageable and reportable.

Suppliers bring their own risks into the organization through products, services, infrastructure, data access and dependencies. In the BowTie Portal, supplier risks can be modeled using the same logic as internal risks.

This integrates threats, consequences, barriers, risk values and measure status into the company-wide situational picture.

The risk register is the structured collection of all relevant risks. In the BowTie Portal, this becomes more than a list: every risk has a model structure, threats, consequences, barriers, assessments, responsibilities and history.

This turns the risk register into a manageable data foundation for risk inventory, situational picture and management decisions.

The risk profile describes the current overall risk exposure of an organization, a business unit, a process, a plant or a supplier.

Over time, the risk profile shows whether barriers are effective, whether new threats are emerging, and whether the risk situation is improving, stable or becoming more critical.

ICS stands for Internal Control System. ERM stands for Enterprise Risk Management, i.e. company-wide risk management. The BowTie Portal supports both perspectives: controls are modeled as barriers, risks are assessed across business units and consolidated into a situational picture.

This allows operational controls, risk assessments, responsibilities and management reports to be managed in a shared structure.

For structured recording, threats can be organized into dimensions: organizational risks, process risks, laws and standards, non-IT technological risks, information technology, personnel risks, partner/customer/infrastructure risks, force majeure and natural events, human misconduct, and financial risks.

These dimensions help to search systematically during the risk inventory and avoid overlooking significant triggers.

Consequences can be organized into impact classes, for example claims for damages, reputational damage, repair/replacement, inability to deliver, quality problems, loss of market price, customer loss, regulatory violation, breach of contract, health impacts, payment default, loss of production capacity, loss of human resources, or inefficient production.

Impact classes support the assessment of consequence costs and the prioritization of reactive barriers.

The factory CRM is a contact control center that maps the person in the full reality of their professional life. A person is managed with name and contact details and, beyond that, with roles, relationships, responsibilities, assistants, skills, deadlines, documents, delegations and development paths.

This creates a genuine overall picture of the person within the company, the project, sales, the organization and the process – as a manageable relationship and responsibility object.

More: CRM Contact Management ↗

In the factory CRM, the person is at the center – as a living object rather than a mere data record. It becomes visible who a person really is, what functions they perform, what responsibility is attached to them, and which processes depend on them.

Roles, relationships, appointments, delegations and tasks form a shared overall picture. This actively supports succession, knowledge transfer, responsibility handover and personal care.

A person has many facets: they can be a manager and, at the same time, an employee, a project owner, a customer, a supplier, an auditor, an apprentice, a skill holder or a knowledge holder. Through an assistant, calls, appointments and coordination work realistically.

The CRM brings these roles together in one person and shows the appropriate context for each process – with a clean, duplicate-free structure.

People take on roles, hand off responsibilities, build skills or leave the company due to age. The factory CRM makes these relationships visible and manageable.

On a role change, departure or responsibility handover, the system shows which skills, tasks, relationships and responsibilities are being transferred. This turns the CRM into a succession, skill and responsibility control center.

The three-dimensional factory rights concept secures confidentiality across three levels: access to the person as a whole, access to individual attributes, and owner rights per record.

Roles, attributes and owner rights precisely control who may see a person, change an attribute, pass on information, or be responsible for a record.

The person themselves is visible in a role-appropriate way. Some users see the full contact, others see a suitable excerpt – each exactly within the scope of their permission.

This gives every role the appropriate view of the person, tailored to task and responsibility.

Even within a person, individual pieces of information remain finely controllable. Phone number, private contact details, assistant, roles, skills, assessments, documents or sensitive notes are visible, readable or editable depending on the role.

This gives every role exactly the attributes their task requires.

Every record has an owner who maintains, edits and passes it on comprehensively. When handed off to a next owner, the owner rights transfer along with it.

This creates clear responsibility for maintenance, currency and personal care of every person.

The owner dimension makes the CRM particularly strong: the owner sees when they last worked on a person, which activities are open, and where attention is needed. Personal reminders keep important people top of mind.

This supports both central control and each owner's self-steering: every owner actively manages their contacts, relationships, tasks and reminders.

The portal imports technical bulk data, stores it in history, links it with objects and presents it as interactive diagrams, heat maps, 3D models, dashboards and management situational pictures.

Its particular advantage is the fast visual processing of differently structured bulk data: detail data becomes clear patterns, profiles and situational pictures.

More: Data Visualization Portal ↗

A single load-profile meter already delivers 96 values per day at 15-minute intervals. Across months, meters or locations, large volumes of data arise whose patterns become especially quick to recognize visually.

This is exactly where visualization delivers its benefit: it makes load peaks, operating times and anomalies visible at a glance.

The workflow is end to end: data is imported, stored in history, visualized and monitored. Historization allows the comparison of time periods, objects and references.

This keeps every development traceable and comparable across days, weeks and months.

Typical sources include CSV, Excel, database exports, REST APIs, specialist systems, SCADA systems, ERP systems, GIS systems, asset management systems, IoT platforms, and meter and sensor data sources.

Existing data sources are imported quickly and linked to objects.

WatchDog functions monitor threshold values, missing readings, notable load peaks or defined events. This generates alerts, review tasks, reminders or push notifications.

This means anomalies are actively reported and lead directly to appropriate actions.

The trend over time remains the basis for detailed analysis, plausibility checks and drill-down – for electricity, gas, water, sensor and process values.

Minimums, maximums, averages and peaks become visible; time periods, objects and references can be compared.

Heat maps show intensities, repetitions and time windows especially fast: daily, weekly and monthly patterns, operating hours, weekends and shift patterns.

Notable time periods and recurring load peaks stand out immediately.

Every day is displayed as its own profile over 24 hours. Placed one behind the other, these daily profiles form a spatial consumption object.

This makes load peaks, operating hours, weekly rhythms, plateaus and outliers stand out clearly – changes over time are instantly recognizable.

Technical detail data is condensed for the business unit and management into steering-relevant information: top consumers, trends and status tiles.

The drill-down leads from the overall picture down to a single value and sets priorities for operations, controlling and management.

Geographically structured data appears as overview points on a map and can be directly linked with locations, objects, customers, plants or service cases.

Sales example: a map section shows a planned customer visit along with the prospects in the defined radius. This makes additional sales contacts, clarification calls and on-site visits easier to plan.

Suitable processes include network operations, asset management, maintenance, incident management, control-center processes, plant monitoring, inspection and audit processes, facility management, production, quality management, technical evidence management and field service.

Wherever measurements, condition data, fault reports, inspection reports, maintenance data or location information arise, visualizations make patterns, clusters, deviations, priorities and the need for action visible.

The facility object is the control center's central information object. A facility object can, for example, be: a property, a building, a section of a building, a room, an apartment, a technical plant, an inspection-obligated object, a contract, a document, a maintenance case, a measure, an order or a contact person.

Every facility object brings its own information, deadlines, documents, obligations, costs and measures – and thereby becomes manageable.

More: FM Facility Management ↗

The structure of the Facility Management Control Center is set up through customization – without programming. You define levels (e.g. property → building → rooms), attributes per object (e.g. status, area, monthly heating cost, particulars) and additional object categories (e.g. fire doors within a building).

This way, the control center follows your inventory and your processes.

Generic means: the system's core functions are programmed as integrable modules and can therefore be used for different levels and object types.

Example: documents, appointments, contacts, tasks, statuses, reminders, approvals and history all work for buildings just as they do for rooms, apartments, technical plants, fire doors, contracts or maintenance measures.

This lets even highly individual facility structures be mapped quickly and traceably.

The WatchDog automatically monitors dates and deadlines. Any deadline – including with individual lead times – can be used for monitoring: inspection dates, maintenance, document expiry dates, reminders or deficiency-correction deadlines.

The WatchDog can also check whether required corrections happened within set deadlines – and escalates to the defined party if the deadline is missed.

This way, the control center shows the facility manager in good time where an inspection, measure or decision is due.

Here, MPM refers to the cross-cutting management of multiple objects, measures and programs: a portfolio overview across all properties, prioritization of measures, budget and capacity planning, annual planning for inspections and maintenance, management reporting, and approval of measure packages.

Example: management sees all upcoming maintenance measures across multiple buildings, assesses priority, cost and urgency, and decides which measures to approve.

More: factory Project Control Center ↗

SPM stands for the operational management of individual cases: a single maintenance measure, inspection, servicing, tenant request, damage report, inspection tour, or a single modernization project.

Example: for a defective fire door, a case is created – with description, photos, inspection documents, responsible parties, deadline, service provider, costs, approval and completion documentation.

Task: make consumption, cost and condition information for energy, heat and cooling visible by object – with comparisons across time periods and buildings, notable anomalies, and derived energy measures.

Example: heat consumption at Building C is markedly above comparable buildings in the portfolio. The control center makes the deviation visible, links it to the building and its plants – and from that insight a measure is directly created with responsible party, deadline and progress tracking, instead of a figure getting lost in a spreadsheet.

Task: manage all inspection-obligated objects in one register with obligation type, standard deadline, responsible party, service provider, evidence document and escalation rule – including documented delegation of obligations to internal or external parties.

Example: the recurring elevator inspection in Building B appears in the register with deadline, responsible inspector and stored evidence. The FM control center shows which obligation exists and also whether it has been fulfilled, documented and tracked – in an emergency, the decisive proof of operator responsibility.

Task: build a reliable budget forecast from cost history per object, expected measures, recurring maintenance costs and identified renovation needs – with priority classes and portfolio comparison.

Example: the cost history of the heating systems across all buildings shows rising repair costs for two systems. The control center turns this into a budget forecast for the coming year – management recognizes the renovation need before the breakdown, not after.

Task: bundle multiple individual measures into a program, evaluate options, steer approvals, monitor project status, and prepare management decisions with documents.

Example: a facade renovation across three buildings is set up as a program: options with cost and benefit, approval per measure package, ongoing status per building. The FM control center keeps individual measures, budget and decisions together – following the same control-loop logic as the project control center.

Task: give customers, tenants and users direct, object-based access to their information via an FM portal – costs, consumption, documents and cases.

Example: the landlord of an office tower gives its customers access to their monthly climate-control costs – per unit, with evidence and history. The FM control center delivers the data directly from the object structure, instead of the management team sending out evaluations by email every month.

Task: capture damage and faults directly on site – with photo, object reference, priority and automatic forwarding as an order to the responsible handler or service provider.

Example: the caretaker photographs a damaged basement door with their smartphone. In the control center a case is created immediately at the correct object – with image, priority and order. Nothing gets lost on paper or in phone calls, and completion is documented.

Task: conduct handovers and acceptances of units, areas or trades in a structured way – with checklists, protocols, photos, meter readings, identified deficiencies and measures generated from them.

Example: when handing over apartment A-14, the protocol is created digitally at the object: meter readings, photos, two identified deficiencies – which immediately become measures with a deadline before the next tenant moves in. The FM control center connects handover, evidence and follow-up tasks seamlessly.

Task: manage maintenance and lease contracts directly at the relevant object – with terms, notice periods, contacts, conditions and documents, monitored by the WatchDog.

Example: the maintenance contract for the elevator in Building B is attached to the plant object; its notice period is stored as a WatchDog deadline with lead time. The FM control center reminds in good time before a silent auto-renewal – and the "renew or re-tender" decision is prepared with the service provider's usage history and costs.

Definition by project biz ↗

Control centers are technical systems for the online steering of complex processes. They are used wherever many different pieces of information need to be continuously brought together, evaluated and translated into fast, well-founded decisions.

The factory Project Control Center applies this principle to project management. It accompanies the project process from the first idea through the go/no-go decision to successful completion, and helps management steer measures and projects in a targeted way.

To this end, strategic goals, resources, priorities and other directives are captured systematically. The control center makes competing requirements visible, evaluates goals and feasibility against existing constraints, and thereby creates a solid basis for deciding which projects to start, prioritize and implement.

The two areas of Multi-Project Management (MPM) and Single-Project Management (SPM) work together here in real time. In the MPM area, management sets goals, priorities and steering directives. In the SPM area, project data from individual projects is captured – for example plan data, actual data, schedule changes, cost developments, resource information or supplier reports.

The Project Control Center condenses this information into steering-relevant metrics and makes it available to the MPM area as a current situational picture. At the same time, decisions from management directly feed back into the individual projects. This creates a closed steering loop: project changes generate management signals, management decisions trigger project actions.

MPM is the management layer across all projects. Unlike the single project, it contains only the essential header data from individual projects – not activity-level details.

• Header data calculated from activity-level data: start, end, total cost, total result (PoP)
• Supplemented with other header data such as project name, key and text information
• Condensed metrics (KPIs & cKPIs) for prioritization and steering
• Drill-down into the associated single project as needed

SPM is the operational layer within a single project and holds all essential data.

• Activity-based planning: schedules including milestones, costs, resources, results (PoP)
• Activity-based actuals: actual costs, actual schedules, actual results (PoP)
• Header data: project name, keys, text information and calculated metrics
• Basis for all condensed metrics in MPM

Target data are directives at the MPM level that must be adhered to – for example strategic budget or schedule goals for a project.

Agile changes are routine here: target data is developed further as needed by the controlling lead via budget adjustment.

Actual data are the real results at the SPM level – what has actually been achieved, consumed or completed in the project so far.

Together with plan data, they form the basis for target-actual comparisons and forecasts.

Plan data are the details at the SPM level describing how the target directives are to be achieved – for example schedules, costs and resources per activity.

It is the operational translation of the strategic target data into a concrete project plan.

Forecasts are mathematical evaluations based on various recognized methods – for example Earned Value Management (EVM) or progress-degree methods (PoP).

They combine target, actual and plan data into a forward-looking assessment of how costs, schedules and results are likely to develop.

Classic budget approval thinks in a fixed cycle: planned once, approved once, done. Agile projects work differently – priorities, scope and resource needs shift continuously.

That's why the Project Control Center reflects budget adjustment rather than rigid approval: the controlling lead can increase, decrease, or release planned budgets at any time – and the responsible project manager sees the decision reflected back immediately.

This keeps the budget as flexible as the project itself, without losing control over approvals.

The Cube is the collection – or copy – of all activities from all single projects, one layer below the pure MPM header data.

It is needed, for example, for resource calculation: at the pure MPM level it's not possible to determine when which resource is needed – that requires access to the activity data from all projects.

KPIs are metrics automatically calculated from standard plan and actual data – with no extra effort for the project manager.

cKPIs (combined KPIs) arise from combining multiple metrics and deliver deeper insight into planning quality, productivity and cost-effectiveness.

Guiding principle: minimal data entry – maximum informational value.

PoP stands for a planned result unit, independent of effort. Example: 100 tables = 100 PoP, 30 screens = 60 PoP, 50 pages of a manual = 25 PoP, 10 meetings per employee = 10 PoP.

This measures completion by actual results and allows a Change Request to be submitted in cases of overachievement.

This complements budget consumption with the remaining-work perspective: budget consumption asks "plan minus actual," while completion degree asks "plan minus remaining" – together they give a realistic picture.

Two simple but central consumption metrics – the basis for cost-effectiveness and goal achievement.

Measures productivity: were the completed activities realized at the planned cost? Only meaningful when planning and actuals use the same structure.

Measures the cost-benefit ratio: was the budget needed to achieve the result as high as planned? A measure of investment efficiency.

A measure of the overall effectiveness of the project. Example: CD = 50%, budget consumption = 50%, time consumption = 50% → goal achievement = 100%. With CD = 10%, budget consumption = 10%, time consumption = 20%, only 33% results.

Shows how long it takes until the first activity of a project is completed – only then can a reliable CPI be measured.

The longer this dead time, the later it becomes apparent whether the plan was realistic: a direct measure of planning risk.

The more activities are "open" at the same time, the greater the risk at acceptance. In actuals, this value corresponds to the maximum outstanding commitment (obligo).

Answers the question: how many people are needed at peak load – e.g. how many experts with a specific skill are needed at the same time? Baseline loads should be considered separately here.

Shows how much budget a project manager is responsible for per day on average – an indicator of the maturity level required of the project management deployed.

Shows how finely a project is structured – an indicator of the maturity of project planning.

A rough estimate of how much project management capacity a project needs – based on a company-specific experience value.

The Project Control Center's metrics catalog is extendable. New metrics can be added during live operation – matched to your steering logic, your industry and your data base.

Just let us know which metric is still missing for your management.

Daily work is shaped by a flood of emails, chat messages and tickets – important information gets buried in it, and no one reacts on their own in time.

That's why the Project Control Center actively "drives" the workflow: it doesn't send a generic email, but a specific request to exactly the responsible person – with a link straight to "their" data screen where the decision or input is due.

The result: no searching for the right place in the system, no back-and-forth questions – just one click to the concrete task.

More: Workflow Engine ↗

DMS stands for Document Management System. In the project control center, the DMS engine automatically links every relevant change with its evidence – a protocol, an approval, a contract, or a supplier document.

This keeps every metric, every escalation and every decision in the control center provable, without documents having to be manually searched for or linked.

More: DMS & Document Control Center ↗

PRM stands for Partner and Role Management. The PRM engine automatically determines who is responsible for a case – role, person, team or decision-maker – even across company boundaries, for example with external suppliers or partner firms.

Only with PRM does the workflow know exactly who a request, approval or escalation needs to be addressed to.

More: CRM Contact Management ↗

KRITIS stands for critical infrastructures – organizations and facilities whose failure would have significant consequences for public supply or public safety. This includes, among others, the energy, water, health, transport, food, financial and insurance, and information technology and telecommunications sectors.

Operators of critical infrastructure in Germany are subject to special legal requirements for IT security (including the BSI Act and the BSI KRITIS Regulation): they must comply with the state of the art, report security incidents, and regularly prove their precautions.

KRITIS-compliant delivery means for the Project Control Center: on-premise operation takes place entirely within your own secured infrastructure – without cloud requirements, optionally in isolated networks, with traceable update processes and a system architecture that fits your security and evidence requirements.