IFS Analytics & Lobbies

Lobbies are configurable, role-based dashboard pages inside IFS itself. Rather than sending people to a separate reporting tool, a lobby puts the measures a particular role cares about on a page they already use, with the ability to click from a tile straight through to the underlying records. A maintenance planner's lobby shows overdue work and upcoming plans; a controller's shows unposted transactions and project margin; a service manager's shows jobs at risk of breaching SLA today. The operational value comes precisely from the embedding: a number you see while doing the work changes behaviour in a way that the same number in a weekly report does not.

It depends on what you are trying to answer. For operational decisions inside IFS processes, lobbies and built-in reporting are usually the better answer because they are immediate, permission-aware and drillable to source. For analysis that spans IFS and other systems — CRM, external market data, a group consolidation across non-IFS entities — or for heavy historical modelling and data science work, a dedicated BI platform is the right tool and IFS supports data access for it. The pattern worth avoiding is rebuilding IFS's own operational reporting inside a BI tool, which adds latency and creates a second version of the truth that someone then has to reconcile.

To a meaningful extent, yes. Quick reports and query capabilities let capable power users build their own views against the data model without waiting on a development cycle, and lobbies can be configured rather than coded. In practice the constraint is rarely the tooling and almost always data literacy and governance: without some discipline about who defines a measure, organizations end up with several dashboards that answer the same question differently, which is worse than having none. ESS typically sets up a small governed set of measure definitions during implementation and then enables self-service on top of them — that way self-service accelerates people rather than fragmenting the numbers.

Lobbies and reports answer questions you anticipated when you designed them. The questions that matter often are not anticipated — someone wants to know something specific, once, and building a report for it is disproportionate. That is the gap ESS Fusion AI's live ERP data capability addresses: asking your IFS data a question in plain language and getting an answer back, without writing a query or waiting on a report request. It complements lobbies rather than replacing them, because the recurring operational measures still belong on a dashboard where people see them without asking. See the live ERP data page for how it works.

It is a real consideration and worth raising during planning rather than discovering at go-live. How much transactional history you migrate is a deliberate decision with a cost attached, and the trade-off is that migrating everything is expensive and slows the cutover, while migrating too little leaves finance and operations unable to compare against prior periods. The usual answer is migrating the balances and open items you need to operate plus a defined window of transactional history, and retaining deeper history in an archive or reporting store that remains queryable. ESS sizes this explicitly during a migration assessment so it is a decision rather than an accident.