View Categories

Start Here

4 min read

INTERA helps companies understand what is happening across their business without forcing managers to collect information manually from multiple systems.

It connects to existing business software, reads operational data, turns that data into structured Assets and Metrics, and presents the results through role-based dashboards.

INTERA does not replace billing, CRM, ERP, accounting, logistics, or network management systems. It works above them as a visibility and operational control layer.

The main principle is simple:

Know what is happening without asking anyone.

What is INTERA? #

Most companies already use several operational systems.

A telecom company may use separate platforms for billing, customer management, network monitoring, accounting, support, and partner management.

A shipmanagement company may use different systems for fleet operations, procurement, crewing, finance, compliance, and maintenance.

Each system may contain useful information, but the full business picture is usually spread across many applications, reports, spreadsheets, and manual checks.

INTERA brings selected information from these systems into one structured environment.

It allows you to:

  • connect existing business systems;
  • define important business objects;
  • calculate and monitor Metrics;
  • create role-based dashboards;
  • control which users can access each dashboard;
  • highlight important conditions, delays, and problems;
  • retain Metric history for trend analysis.

INTERA is designed to show the information that matters to a specific role.

For example:

  • a Finance Manager may need overdue balances, unpaid invoices, and cash collection status;
  • a Service Assurance Manager may need service availability, unresolved incidents, and affected customers;
  • a Billing Operations Manager may need billing completion, rejected records, and reconciliation status;
  • a Fleet Manager may need vessel status, maintenance risks, and delayed operations.

Instead of giving every user access to every source system, INTERA presents a focused view of the information relevant to their responsibilities.

What INTERA Is Not #

INTERA is not intended to replace the systems that already operate your business.

It is not:

  • a billing platform;
  • a CRM system;
  • an accounting system;
  • an ERP system;
  • a ticketing system;
  • a network monitoring platform;
  • a general-purpose data warehouse;
  • a traditional business intelligence platform.

Your existing systems remain the primary source of operational data.

INTERA connects to those systems, reads selected data, applies business logic, and presents the result in a clearer operational format.

In most Stage 1 use cases, INTERA works as a read-only visibility layer. The original operational action is still completed in the source system.

How INTERA Works #

INTERA uses a small number of core concepts.

A typical data flow looks like this:

External System
    ↓
Integration
    ↓
DataSource
    ↓
Asset or Metric
    ↓
Widget
    ↓
Dashboard
    ↓
Role and User

Each part has a specific purpose.

External Systems #

External systems are the applications that already contain your company data.

Examples include:

  • billing systems;
  • accounting software;
  • CRM platforms;
  • ERP systems;
  • network management systems;
  • logistics platforms;
  • manufacturing systems;
  • shipmanagement systems;
  • SQL databases;
  • spreadsheets and structured files;
  • external data services.

INTERA does not require all company data to be copied into the platform.

Only the data needed for specific Assets, Metrics, and dashboards should be connected.

Integrations #

An Integration allows INTERA to communicate with an external system.

Depending on the source system, an Integration may connect through:

  • an API;
  • a database connection;
  • a file;
  • a secure file transfer;
  • another supported communication method.

An installed Integration can be configured one or more times.

For example, the same accounting Integration may connect to:

  • the production accounting system;
  • a second company database;
  • a regional subsidiary;
  • a testing environment.

Each configured connection is called an Integration Instance.

DataSources #

A DataSource is a structured dataset exposed by an Integration.

Examples include:

  • invoices;
  • customer balances;
  • support tickets;
  • network alarms;
  • active contracts;
  • sales orders;
  • payments;
  • supplier records;
  • vessels;
  • shipments;
  • production batches.

A DataSource defines:

  • which data is available;
  • which fields are returned;
  • which filters can be applied;
  • which time period options are supported.

INTERA uses DataSources to populate Assets and calculate Metrics.

Assets #

An Asset is a meaningful business object stored in INTERA.

Examples include:

  • a customer;
  • a supplier;
  • a product;
  • a contract;
  • a bank account;
  • a vessel;
  • a vehicle;
  • a network node;
  • a warehouse;
  • a department.

Assets are created according to Asset Types.

An Asset Type defines the structure of an Asset, including its fields and expected data.

For example, a Vessel Asset Type may contain:

  • vessel name;
  • IMO number;
  • operator;
  • current status;
  • next inspection date;
  • assigned superintendent.

An Asset may be created manually or synchronized from an external system.

Metrics #

A Metric is a value that describes a condition, result, amount, date, status, or location.

Examples include:

  • monthly revenue;
  • overdue balance;
  • open incident count;
  • service availability;
  • last payment date;
  • stock level;
  • vessel position;
  • billing completion status;
  • collection rate;
  • customer churn percentage.

Metrics can be:

  • entered manually;
  • synchronized from an Integration;
  • calculated from DataSource results;
  • calculated from other Metrics;
  • combined into a health score.

A Metric may be independent or linked to an Asset.

For example:

  • a company-wide monthly revenue Metric is independent;
  • an outstanding balance Metric may be linked to a Customer Asset;
  • a signal quality Metric may be linked to a Network Site Asset.

INTERA can keep historical Metric values, allowing users to see how a value changes over time.

Dashboards #

A Dashboard presents information to users through Widgets.

A Dashboard may contain:

  • one or more pages;
  • Frames that organize content;
  • Metric values;
  • Asset information;
  • status indicators;
  • tables;
  • charts;
  • navigation controls;
  • interactive Widgets.

Dashboards are designed around business roles rather than around source systems.

A Finance Dashboard may combine data from billing, banking, accounting, and CRM systems.

A Service Assurance Dashboard may combine network alarms, customer incidents, service status, and support information.

This allows users to see one operational picture without opening several applications.

Roles and Access #

A Role defines what a user is responsible for and which Dashboards they can access.

Examples include:

  • Finance Manager;
  • Billing Operations Manager;
  • Service Assurance Manager;
  • Network Operations Manager;
  • Procurement Manager;
  • Fleet Manager;
  • Customer Operations Manager.

A Dashboard can be assigned to one or more Roles.

Users receive access according to their assigned Roles.

This ensures that each user sees information relevant to their responsibilities without exposing unnecessary dashboards or data.

Role Packages #

A Role Package is a predefined collection of INTERA configuration designed for a particular business function or industry.

A Role Package may include:

  • Roles;
  • Dashboards;
  • Asset Types;
  • Metric definitions;
  • thresholds;
  • recommended Integrations;
  • mapping requirements;
  • industry-specific business logic.

Role Packages reduce the amount of work required to configure INTERA.

Instead of designing everything from the beginning, an administrator can install a package and then connect it to the company’s existing systems.

Role Packages may still require mapping and configuration because external systems often use different names, fields, and data structures.