Using the MAS 9 readiness checklist: a worked example

A checklist is only useful once you’ve answered it. So in this article we’ll work through the free MAS 9 readiness checklist for one hypothetical Maximo 7.6 system, area by area, and see what it turns up.

Almost every site I look at knows its version number. Almost none can tell me which of their Java classes still matter.

The system belongs to Meadowbank Water. Meadowbank is made up, but it’s built from patterns I see again and again: a mid-sized utility on Maximo 7.6.1.2, with the Scheduler and Spatial add-ons. It has about 300 users, 60 field technicians on Maximo Anywhere, and one large finance interface that everyone is slightly afraid of.

For each of the checklist’s 8 areas, we’ll pick the 2 or 3 checks that matter most, show where in Maximo you find the answer, and give Meadowbank a rating:

• Green Answered, and nothing to worry about.
• Amber Answered, but there’s work to plan.
• Red Not answered yet, or a real risk to the project.

At the end you’ll find Meadowbank’s full scorecard for all 34 checks, and the top 5 risks that go on its project plan.

1. Know what you have

This is the biggest area, with 7 checks, and it’s where most sites discover they know less than they thought.

Record your version. Start with Help → System Information. It lists the exact version and fix pack, plus every industry solution and add-on installed. Meadowbank is on 7.6.1.2, which can upgrade directly to MAS 9, with Scheduler and Spatial. Green

List every Java customisation. Custom Java classes show up in Database Configuration, in an object’s Class field. That’s fine for one object, but slow for 900. A query finds them all at once:

-- Objects and attributes with a custom (non-IBM) Java class.
-- IBM's own classes start with psdi. or com.ibm. (add-ons such as Scheduler use com.ibm.).
-- A few IBM objects hold a placeholder such as 'x', so only names with a dot are counted.
SELECT objectname, classname FROM maxobject
 WHERE classname LIKE '%.%'
   AND classname NOT LIKE 'psdi.%' AND classname NOT LIKE 'com.ibm.%';
SELECT objectname, attributename, classname FROM maxattribute
 WHERE classname LIKE '%.%'
   AND classname NOT LIKE 'psdi.%' AND classname NOT LIKE 'com.ibm.%';
-- Cron tasks with a custom class
SELECT crontaskname, classname FROM crontaskdef
 WHERE classname LIKE '%.%'
   AND classname NOT LIKE 'psdi.%' AND classname NOT LIKE 'com.ibm.%';

Meadowbank found 42 custom classes. Only 18 are still used, and 12 have nobody who can say what they do. Amber

List your configuration. Automation scripts, escalations and workflows come across with the database. Still, you need to know what you have, because every one needs testing.

SELECT status, COUNT(*) FROM autoscript GROUP BY status;
SELECT COUNT(*) FROM escalation WHERE active = 1;

Map every integration. External Systems and Publish Channels list what’s defined, but not what’s actually in use, so ask the teams on the other end too. Meadowbank has 14 integrations. Its finance interface is the one that matters.

List your reports. Report Administration lists every report. The report usage log tells you which ones people actually run:

-- Reports run in the last year
SELECT reportname, COUNT(*) AS runs
  FROM reportusagelog
 WHERE enddate > SYSDATE - 365
 GROUP BY reportname ORDER BY runs DESC;

Meadowbank has 220 reports, but only 60 ran last year. That’s 160 fewer to retest. Amber for the area as a whole, because the inventory is done but the decisions aren’t.

2. Licensing and access

Map users to access levels, and choose authorized or concurrent. Both answers come from how often people really log in. If login tracking is switched on, it tells you. Many sites have it switched off, in which case start collecting now, so you have a few months of data before you decide.

SELECT userid, MAX(attemptdate) AS last_login
  FROM logintracking
 WHERE attemptresult = 'LOGIN'
 GROUP BY userid ORDER BY last_login;

At Meadowbank, 180 of 300 users log in less than once a week. They’re the natural candidates for concurrent access, which only uses AppPoints while someone is logged in.

Tidy security groups first. Groups with no members are the easy wins:

SELECT groupname FROM maxgroup
 WHERE groupname NOT IN (SELECT groupname FROM groupuser);

Meadowbank has 95 groups, 30 of them empty. Amber The numbers are known, but nobody has agreed the access levels with IBM yet.

3. Platform and hosting

Decide where MAS will run, and who runs it. MAS runs on Red Hat OpenShift: your own cluster, a public cloud, or a managed service. Meadowbank’s infrastructure team has never run OpenShift, and it’s still torn between building its own and paying for a managed service. That decision drives cost, skills and timeline, so it can’t wait. Red

4. Customisations and integrations

Decide what happens to each customisation. Every one of Meadowbank’s 18 live Java classes needs a decision: retire it, replace it with configuration, rewrite it as an automation script, or carry it forward in the customisation archive. None has been decided yet. Red

Check integration authentication. MAS uses API keys for REST access. Meadowbank’s finance interface uses JMS with basic authentication, so it needs rework and a full end-to-end retest with realistic volumes. Red

A note on the SQL. The queries are for Oracle. On Db2 use CURRENT DATE - 365 DAYS, and on SQL Server use DATEADD(day, -365, GETDATE()). Run them on a copy, not production, and check the table names against your own release.

5. Mobile and the user experience

Plan the move off Maximo Anywhere. Anywhere isn’t available in MAS 9, so Meadowbank’s 60 technicians move to Maximo Mobile. That means new devices to check, new ways of working in the field, and training for every depot. It’s a project in its own right. Amber It’s known, but not yet planned.

Plan the move from start centres to Operational Dashboards. Meadowbank has 9 role-based start centres. They’ll still work on day one, so the job is deciding which roles move to dashboards first, not doing it all before go-live.

Part 2 of this series, Your first morning on MAS 9, covers what users notice in detail.

6. Data, testing and cutover

Clean data before you move it. Meadowbank has 40,000 items that nobody has ordered in five years. Moving them costs nothing on day one, but they clutter every lookup for years. Obsolete them before the move.

Rehearse on a copy of production. There’s no trial migration in Meadowbank’s plan yet. A full rehearsal, with every step timed, is the only way to know how long the real cutover will take, and whether the rollback works. Amber

7. People and training

Identify what changes for each role, and train super users first. Meadowbank has no training plan and no named super users. It’s the most common red on any scorecard, because the technical work feels more urgent. It isn’t: a technically perfect upgrade still fails if planners can’t find their work orders on day one. Red

A good start is a short list per role of what’s new, what’s moved and what’s gone, plus a one-page guide for the first week. Part 2’s day-one cheat sheet is a template.

8. AI worth planning for now

None of MAS 9’s AI features is needed on day one. What they change is which data is worth cleaning and migrating now.

Are your work order descriptions good enough for AI? Problem code suggestions learn from the long descriptions on past work orders. Meadowbank read 50 recent ones: most were blank or said “see above”. A machine can’t learn much from that, and neither can a new planner. Amber

Will planners use history they can now find? Similar Work Orders surfaces past jobs like the one in front of you. It’s a good reason to migrate history rather than archive it.

Meadowbank’s scorecard

All 34 checks: 8 red, 19 amber and 7 green. The reds cluster in three areas: hosting, customisations and people. That’s typical, and it’s exactly why the checklist exists.

Meadowbank’s top 5 risks

If you remember one thing

A red rating isn’t a failure. It’s a line on the project plan, found early enough to do something about it. The only bad scorecard is the one nobody filled in.

What’s next

Part 4 looks at users and security: creating users in the suite, security groups, role-based app security, and which settings live where. You can see all ten parts of the series, and what’s coming, on the series page.