About the Project
Links to our new application
Quick Links
Product Vision Board (in progress)
| View file |
|---|
| name | Product Vision Board.pdf |
|---|
| height | 250 |
|---|
|
Product Roadmap
| View file |
|---|
| name | Vessel Registry Product Roadmap.pdf |
|---|
| height | 250 |
|---|
|
Overview (in progress, copied from Gate 1 Deck)
- The program is unable to meet its services standards given the burden created by the current paper-based process therefore; at high risk of remission with the introduction of the new remission policy.
- There is an opportunity for the Vessel Registry business line to undertake an end-to-end service design that is user-centered and driven by operational needs. This work is currently supported by an MOU signed with the CSPS.
- MSS business lines require information collected during the Vessel registration process to manage and deliver their programs to Canadians and the Canadian industry. The management of the vessel registration program, its data, and related information are fundamental to other business processes and programs within MSS (e.g. Marine Insurance Unit, Regional Inspection programs), and within other TC groups (e.g. Navigation Protection Program and Wrecked, Abandoned, and Hazardous Vessels Act-WAHVA). However, the current registry systems are not connected to other program applications and do not provide direct access to vessel tombstone data (lack of interoperability and data-sharing capacity for end-users).
- Vessel registration data also supports the information requirements of other government departments (i.e. DFO, CBSA, and CRA) to allow them to fulfill their mandates. However, the current registry systems do not have reporting capabilities.
Project delivery
To facilitate the process of design and development for the Vessel Registry project, we are following the UK Government methodology for Agile service delivery laid out in their
Service Manual.The service manual recommends breaking down a service design project into phases:
Product Vision
What are we looking to provide, and what problems are we trying to solve?
For registrars
Fully digital
- No need to handle paper documents
- Ability to seamlessly work remotely
- All tools and material Centralized
Service request processing
- Process payment
- Easily see payment status (has this service been paid for?)
- Training material
- Legal opinions
- Streamline processing of service requests
- Can review and process requests, issue certificate without changing applications
- Incorporate business rules and procedures into app to ensure consistency and reduce mental load
- Add guidance and instructions to help with training and onboarding
Cut down administrative overhead
Facilitate communication with clients
- Automatically generate correction correspondence
- Communicate with client through application?
For internal TC staff
- Reporting and analytics for management
- Access to relevant data for inspectors and policy
- Ability to flag and bring forward vessels of concern for further action
- Link between Registry and Inspection services to easily flag issues for verification
- Keep data up to date and correct
For clients
Submit online
- Manage personal details and vessels
- View status
Streamline submission process
- Eliminate separate paper forms, simpler way to collect information
- Fewer things to fill out
- Dynamic digital forms based on client needs
For external partners (e.g. enforcement, search and rescue, brokers etc.)
- Enhanced data access to facilitate operational needs
- Ability to submit and manage requests on behalf of clients
Desired Business Outcomes
The following is a list of desired business outcomes (also shown in DOS 32801):
OUTCOME A: Increase compliance with Government of Canada on service directives and programs
- BO1: Reduce time to process client requests to meet 30 day service standard to meet cost recovery objectives (compliance with Service Fees Act)
- BO2: Collect and provide the data necessary for cost recovery to meet its objectives (compliance with Service Fees Act)
- BO3: Increase user (client) satisfaction (compliance with the Policy and Directive on Service and Digital)
- BO4: Compliance with Government of Canada on the Directive on the business number
OUTCOME B: Increase Efficiency of Business Processes
- BO5: REDUCE THE AMOUNT OF INCOMPLETE AND ERRONEOUS APPLICATIONS FROM CLIENTS
- BO6: REDUCE THE NUMBER OF CALLS AND EMAILS CAUSED BY INTAKE INEFFICIENCIES
- BO7: REDUCE THE NUMBER OF IRRITANTS CONTRIBUTING TO BUSINESS INEFFICIENCIES
OUTCOME C: Enable digital transformation of Vessel Registry
- BO8: Reduce the number of systems with which internal users must interact
- BO9: Increase adoption rate of digital channels
- BO10:Enable interoperability of data
- BO11:Increase ratio of automated vs manual tasks
- BO12:Improve data quality
- BO13:Reduce time spent on system maintenance
SMART Objectives
About Vessel Registry
About the service
...
Business Capabilities/Services provided
...
Identified Business Capability Services
These may or may not be identified as core services – further analysis required.- Ports?
- Vessel Management
- Owner
- Search
- Mortgage
- Fleet
- Charterer
- Point in Time (see MEMS, MSIS II)
- we need to understand what this means for Point in time; we should be able to do this as a feature
System/Business Capability
These are the Core systems that maintain Vessel information and should be used as the system of record for feature sets/services.All systems do not implement delete?- Ballast Water - full CRUD; own database
- pulls from THETIS and APCIS
- does an update on own data if required
- Port State is same as Ballast Water
- Port State system of record for all foreign vessels
- SIRS - System of Record for Domestic
- SCVRS (Small Vessel) - System of Record
- SRCS (Ship Registry - Large Vessel) - System of Record
- May duplicate Port State data
Systems that use core vessel data or replicated version of vessel data
It is believed that each system implements a search capability, but only a few do a search across the core systems. The majority are only searching within their own data repository, lots a places for error and duplication here.- ACES - query/creat/update; has own database; MPDIS integrated with ACES
- CPSCS-DET - query of port state
- CPSCS-VTP - CRUD of Port State connects to Port State
- CPSCSWQS - read Port State
- CPSCS-INNAV - push an IMO to port database and creates a vessel traffic record (interim which eventually gets validated and links to existing - see Vessel Tracking Record
- EPAIRS - creates records that have IMO number; no links to Port State (data integrity)
- MEMS - read-only from Port State, SIRS, ACES, MTRB, SCVRS for vessel tombstone data and then keeps a read-only copy
- MIUS - stores its own vessels and owners
- MPDIS - maintains its own database
- MSDQT - read from all core systems
- MSIS II - read-only query for Point in Time; keeps data in own database
- NTARS-MSDTS - query of all four core systems and the duplicates the data
- PID - CRUD; maintains its own database
General Notes
- Regardless of what solution we come up with, we need to consider document storage for completed forms and all other required supporting documents e.g. photographs, ship plans, etc.
- Azure Storage, RDIMS, GCDocs??