Ask a technician what they think of Maximo and you will often hear a complaint about the home screen. That screen is the start centre, and a bad one greets people every morning with charts they do not read and links they never click. A good one puts the day's work in front of them the moment they log in. This is a practical guide to designing start centres people actually use, plus the KPI mechanics that make or break login performance.
The start centre components
A start centre is built from portlets. There are five you will use again and again, and understanding what each one is for stops you from reaching for the wrong tool.
- Result set. A live list of records from a query you define. This is the workhorse. "My open work orders", "PMs due this week", "requests awaiting approval", all result sets. Columns are configurable and rows drill through to the record.
- KPI graph. A visual gauge or bar tied to a KPI object. Good for a number a manager needs at a glance, PM compliance or backlog weeks. Not for a technician who needs a list to act on.
- Quick insert. A shortcut that opens a new record in a target application, a new service request or a new work order, without the user hunting through the menu.
- Favourite applications. A small link list to the handful of applications a role opens daily. It replaces menu navigation for people who live in three or four screens.
- Bulletin board. System-wide messages: planned outages, a frozen change window, a reminder about month-end. Central to post, visible to everyone who has it on their layout.
If you are new to the platform, my introduction to IBM Maximo covers where the start centre sits in the wider application menu.
Templates and security groups: who sees what
You do not build a start centre for a person. You build a start centre template, then associate that template with one or more security groups. Every user in a group inherits the template as their default layout. This is the single most important thing to understand, because it decides your whole maintenance burden.
The temptation is to give everyone a bespoke screen. Resist it. If you build one template per person you will spend the rest of the deployment maintaining dozens of near-identical layouts, and every query change becomes a day of copy-paste. Instead, design around roles. Most sites are well served by four or five templates: technician, planner or supervisor, storeroom or procurement, manager, and a light read-only template for occasional users. People who sit across two roles get both templates as tabs.
The template test
Before you create a new template, ask whether an existing one plus a role tab would do. Four or five templates you maintain well beat forty that drift out of date. Fewer templates also means fewer distinct queries hitting the database at login, which matters for the performance point below.
Three worked start-centre designs
Here is how I lay out the three most common roles. Each is deliberately short. A start centre with more than four or five portlets stops being a start centre and becomes a dashboard nobody scrolls through.
| Role | Portlets, top to bottom | Primary type |
|---|---|---|
| Technician | My assigned work · My open jobs by priority · Quick insert: new service request | Result sets |
| Planner | Ready backlog · Jobs awaiting parts · PM due in 30 days · Unestimated work orders | Result sets |
| Manager | KPI row: PM compliance, backlog weeks, overdue statutory · Top-ten overdue work orders | KPI + result set |
Technician.
A technician needs to know what to do next, nothing else. "My assigned work" is a result set filtered to their labour code and open statuses. "My open jobs by priority" is the same data sorted so the priority-one job is at the top. One quick insert lets them raise a service request when they spot a fault outside their current jobs. No KPI graphs. A technician does not need a gauge; they need a list.
Planner.
A planner works the backlog. "Ready backlog" shows work that is approved, estimated, and cleared to schedule. "Jobs awaiting parts" surfaces what is blocked so they can chase the storeroom. "PM due in 30 days" gives them the forward view they schedule against. "Unestimated work orders" is the housekeeping queue, the jobs that cannot be planned until someone puts hours and materials on them. Four result sets, each a distinct action.
Manager.
A manager wants the health of the operation in one glance, then one place to intervene. The top row is three KPI graphs: PM compliance, backlog measured in weeks, and overdue statutory or safety-critical work. Below that sits a single result set, the top ten overdue work orders, so the number they just read as red has names attached to it. That is the whole screen. Managers who ask for twenty KPIs end up reading none.
KPI configuration mechanics
A KPI in Maximo is defined once as an object, then dropped onto any start centre as a graph. Three settings do the real work.
| Setting | What it does | Example |
|---|---|---|
| SQL condition | The where-clause that counts or measures the records the KPI reports on. | Approved PMs completed on time over total due, as a percentage |
| Target | The value you are aiming for; the gauge reads green at or above it. | 95 |
| Caution and alert ranges | The amber and red bands below target, so the graph colours itself. | Caution 85 to 95, alert below 85 |
| Refresh frequency | How often the KPI value recalculates. Not every KPI needs to be live. | Nightly for compliance trends; hourly for live backlog |
The SQL condition is where accuracy lives and dies. Write it against indexed columns, filter by site and status, and test the row count against a report you already trust before you publish it. A KPI that quietly counts cancelled work orders will erode confidence in every other number on the screen.
The slow-login trap
A KPI that runs an expensive query is harmless on your test machine and painful in production. When 300 people log in between 07:00 and 08:00 and each login fires the same heavy aggregate, the database spends the morning recomputing the same number hundreds of times. This is one of the most common causes of a slow Maximo start-up. Fix it by giving KPIs a sensible refresh frequency so the value is cached and read, not recalculated per login, and by keeping the SQL lean. If a number only needs to be right once a day, do not recompute it 300 times before breakfast.
Result-set columns and drill-through
A result set is only useful if a person can read it without scrolling sideways. Start centres are often viewed on laptops and, increasingly, on tablets in the field, so column discipline matters more than it looks.
Choose columns for a small screen:
- Four to six columns, no more. Work order number, description, priority, status, and one date is usually enough.
- Put the column that drives the decision on the left, priority or due date, so it survives a narrow viewport.
- Cut the descriptive noise. Nobody triages by GL account on a start centre.
- Sort inside the query so the row that needs attention is at the top, not buried on page three.
Check the drill-through:
Every row should open the right record in the right application. Click a work order line and it should land you in Work Order Tracking on that exact record, not on a filtered list you have to search again. Test this as the target role, not as an administrator, because a user without the right application access will click a row and hit a blank screen or a permission error. The drill-through is the whole point of a result set; a list you cannot act on is just a report.
Once the screens are right, the natural next step is to make Maximo tell people about exceptions rather than waiting for them to spot a red gauge. That is the job of escalations and notifications. And when leadership wants trends and cross-site rollups the start centre cannot show, that is where connecting Power BI to Maximo earns its place, keeping heavy analytics off the login path.
Change control and review cadence
Start centres rot if nobody owns them. Decide three things before go-live and write them down.
Template ownership.
Every template needs a named owner, usually the Maximo administrator or a super-user for that function. Changes go through that person, not through whoever last had a good idea. A shared spreadsheet of templates, their owning security groups, and their KPIs saves you when someone asks why a query changed.
Personal customisations at upgrade.
Maximo lets users tweak their own copy of a template, move portlets, add a result set. Those personal changes are stored separately from the template, and they are the first thing at risk during an upgrade or a template reset. Set the expectation early that personal customisations are not guaranteed to survive, and that anything genuinely useful should be promoted into the shared template so the whole role benefits and it is protected.
Review cadence.
Put a start-centre review on the calendar, quarterly is a sensible default. Walk each template with a real user from that role and ask which portlets they actually use. Retire the dead ones, fix the queries that have drifted, and check no KPI has quietly become a performance problem as data volumes grew. A start centre is a living configuration, not a one-time build.
Independence note
I am an independent practitioner, not an IBM reseller. I have no commercial relationship with IBM and earn nothing from Maximo licensing. The views here come from configuring these screens on live sites; always confirm behaviour against your own version and the official documentation.
Conclusion
The start centre is the cheapest usability win in a Maximo deployment and the one most often wasted. Build four or five role templates instead of one per person. Give technicians lists, planners queues, and managers a short KPI row with a top-ten result set underneath. Keep the KPI SQL lean and cached so login stays fast, choose result-set columns that read on a small screen, and test the drill-through as the real user. Then put an owner and a review date against each template so the whole thing does not quietly rot. Get this right and people stop complaining about the home screen and start working from it.
Reference material:
Written by Muhammad Abbas
CMMS / CAFM Manager & Enterprise Integration Specialist · 22+ years across ERP, EAM, CAFM and enterprise integration.
Work with me