1. BOXI Upgrade Project Business Stakeholders’ Meeting
Andrew McFarlane, Project Member
Craig Middlemass, Project Manager
Wednesday 27th March, 2013
Overview

2. Welcome Your involvement Why upgrade BOXI? Enhancements Timings
Area migration plan
Training
Communications
Risks and Issues
Q&A
Purpose of session is:
to get you up to speed with what we hope to achieve in the project
to define what some of our hopes and expectations are regarding your involvement
To provide a general update on the project, progress and key deliverables

3. Your Involvement Agree migration timings for your area
Shape key project issues
Contribute to testing, training and communications
2. For example we’re looking at the default user. We have the option to give them html, and they can elect to use java. We want their input into this decision. We’ll circulate more info by .
Stress that without their involvement this is not going to work.

4. Drivers
Current version (“R2”) no longer supported or maintained by SAP
Improved universe design and reporting features in “R4”
An important element of the University’s new BI strategy
No safety net in place if something were to go wrong with the application, we cannot call on vendor support. Also no security patches or feature packs.
This is now an old technology, the latest is two versions ahead. Many gripes solved.
University committed to improving Business Intelligence, having an up to date reporting platform an essential part of that.
Why are we not looking at other solutions?
Makes sense to upgrade BOXI rather than to replace it because many people familiar with the tool and the new one addresses many of their concerns
We are actively looking at tools that will complement BOXI, dashboarding / and other ways of analysing data – please feed into that discussion!

5. Name Changes

6. Enhancements Technical Infrastructure improvements Auditing
Better user account management
New system monitoring capability
New Universe Design tool and format
Build universes from multiple data sources
Potentially reduce cost of universe development by ‘pooling’ all objects into one ‘data layer’ per business area
Infrastructure: move to virtualised machine so can control its resources and performance without the need to change physical machines
IDM connection: Scripts to automatically delete user accounts when people leave the University (no automatic account creation – as new users still ne)
Universe Design – why these two things are good for end-users, BRD page 7 and 8.

7. Enhancements User-facing improvements to Reporting Updated interface
Favourites & Recently Run in one place
Work with multiple reports simultaneously
Auto-saving
List of universes contains description field
More functions
Eradicate Java issues
Works in Safari
Won’t be able to answer all questions about what’s new, but will give demo next month.
Java: two ways of building the reporting interface: we suggest using HTML, but allowing power users to use Java if they want

8. Enhancements Access to BOXI
Updated MyEd channels for BOXI and BOXI Admin console
Button linking to both R2 and R4 on the BOXI channel during migration period
Accessible without need of VPN when off-campus

9. Timings April 13 Up to July 13 August 13 Up to Jan 14 Jan 14 Feb 14
Configure Dev
Configure Test
Pilot Migration in Test
Configure Live
Area by area migration and switchover to R4
Explain the difference between DEV, TEST and LIVE.
What we plan to do in DEV – Configure and trial any set up of the software including user preferences, server settings, etc
What we plan to do in TEST – Carry out a pilot migration to see how the migration tools work and prove their robustness
What we plan to do in LIVE – Carry out the migration Live to Live, operating code freezes during area migrations
What might we ask them to test – Selection of reports and users prior to agreeing general release of a series of universes or reports
When will they get access?
---
March – DEV platform built
June – TEST platform built
July – User Testing of platform
August – LIVE platform built
August onwards – area by area migration and switchover to R4 from R2
January 2014 – decommission R2
February 2014 – project closure
Decommission R2
Project Closure

10. Area Migration Plan Staggered migration – advantages
Shorter code freeze period – resume development of universes / reports more quickly
Team can provide full support to area
These are the steps to be followed in each area
We’ll be setting dates for each of these events
Issues:
Migration of users' personal BOXI reports
Possibility of big bang - advantages for end users - not using two systems
This would entail longer code freeze, say for

11. Training BOXI Upgrade Roadshow eCourses in Reporting
Classroom-based “Getting Started” course
Does not affect current user support arrangements
what we currently have
How will these new things improve upon it?
Can you help?
Local training resources:
Note:
Areas will continue to assume responsibility for developing and maintaining their own user-facing support materials and training courses, and for ensuring that these are delivered to their users in a timely fashion.
You can attend paid for vendor courses in report writing if you need to start developing resources ealry

12. Communications Strategy
Our Audiences
Business stakeholders
Users in Corporate / User Services
College / School Users
All registered BOXI users
Define four groups and their level of project involvement
We understand you may not want us to communicate with their end users
Does this look like the right thing to do
Anyone we’ve missed?
1. Business Stakeholders  - senior admin staff in each corporate services
area (HR, Registry etc) who own universes and reports within BOXI. Their
requirements inform the project decision-making process. They need kept
informed at all stages, and be invited to shape key project issues.
Vehicle: meetings (for input on key themes and to detail project
progress), notifications, demos, vendor supplied training.
Expectation of group: to inform decisions, agree migration plan and
timings, comms to users of their reports and universes around migration
time, update their training resources.
2. Business Area Users - staff in corporate services teams who use BOXI
reports provided by their own area, and perhaps others, but who are not
Business Stakeholders. Our aim is primarily to keep them informed, engage
any feedback. Vehicle: a business consultation group. This group will
comprise staff from across business areas, will be loose-nit, and staff
need not represent their areas or act as postmaster (this being done by
Stakeholders). Expectation of group: to provide feedback on project
issues, provide as people for system UAT.
3. College / School Users - staff who use reports and universes provided
centrally by IS or by business areas such as Registry SACS or Finance. Our
aim is primarily to keep them informed, engage any feedback, and identify
any important business dependencies or roll-out timing issues. Vehicle:
one initial meeting per college (set up by college consultant), with
interested staff forming a college consultation group. This group will
represent their college's interest and also act as postmaster for
communications from the project team and from business areas. Expectation
of group: to provide feedback on project issues, provide as people for
system UAT, do onward comms to college BOXI user base about .
4. All users - all those with an active account within BOXI. Users will
fall into one of three categories above and approached as such. But all
users should be kept informed regarding important project events that
affect the widest audience: to say BOXI will be upgraded, where to find
project info, timescales, training resources, getting involved, when TEST
and LIVE environments are signed off, about how comms for migration of
their universe will be handled, about access to R2 after migration, when
R2 is decommissioned.
5. Universe user group - all users of a given universe should be contacted
by before and after  that universe's migration. Before: timing, what
to expect, own personal reports; after: accessing within R4, advice on
replicating personal reports, when access to R2 will be removed. Who does
it? Stakeholders will do comms to users of their reports and universes
around migration time; project team to assist them, and are responsible
for comms to users of central IS reports and universes.

13. Risks Performance Licensing Lack of stakeholder involvement
Inadequate Training
Virtualized the server, so we can increase memory if needed; and we’ll also do load testing
The new licence model has changed to concurrent users we may need to move to this – implications on cost of volume of concurrent users
We need to keep you interested in this project and make sure it doesn’t lose momentum
If training fails to met the needs of users then we will need this could be seen as a poor implementation

14. Next Steps Next stakeholder meeting Key project resources
Demo of BOXI R4 in April / early May
What user default preferences are
Key project resources
Project website:
What’s new in R4 / Training plan:
Let’s keep in touch – speak to us about your questions