Data Importers
It's important that whilst the necessary reference data is being setup on ACMS, the data that will require importing (e.g. personnel records) is not neglected. It can take time to manipulate the data taken from previous CMS providers into the format required for ACMS, so this work should be ongoing.
Linked below is a page which details all of the AssessTech importers. The required importers for each project depends on the size of the company, as well as the data that is being exported from the previous CMS provider.
Company Structure
Regions and Depots
The regions within the company and the depots that fall within each of these.
This will ultimately affect which candidates each user can see on ACMS e.g. a region manager will only be able to see candidates that are from the associated depots.
T & C Annotation
A Terms & Conditions Annotation is an extra classification for a person in a safety critical role. This is useful if, for example, you have drivers that drive completely different types of trains. It can be used to differentiate any people that work to different terms and conditions.
T&C Annotations are bespoke to a company, you can set up as many as are needed or simply put everyone into a default one.
User Access
Usernames
We normally suggest that the username is set to the first string of the user’s work email address e.g. alice.barrett@assesstech.com - alice.barrett
As of 5.2.3 we are able to enable email address login so that users can either login using their username or email address.
Security Groups
Control the range of people that the user can see by organisational structure. So, a user can be restricted to see just themselves, only people in their depot, only people in their region, or they can be allowed to see everyone.
Also control the range of functions available to the user. It restricts the pages, buttons, and menu items (called user stories) that are available.
Security group functions are split into permissions and user stories. These are all set up by AssessTech but the below spreadsheets can be used to outline what is required for each group.
User Role Groups
Control which people are visible on the system by adding restrictions on a per role basis. So, a user might only be allowed to see guards, or perhaps some combination of different roles.
It's possible to set up user role groups so that assigned users can see candidates who have active/inactive personnel and role records.
For example, a dispatch-only user role group could be set up so assigned users can only see active dispatchers.
Role Records
- Active role: allows users to see candidates with active roles
- Inactive role: allows users to see candidates with inactive (retired) roles
Personnel records
- Active Personnel-YES: This allows users to see Active personnel accounts that don't have any role assigned.
- Active Personnel-NO: Users will not be able to see Active personnel accounts that don't have a role assigned.
Role Reference Data
Role Type
Roles can be added to the system in a flexible way, to allow people with different duties to be handled by the system, in different ways. Whilst originally intended to manage people with safety critical duties, these can also be created for non-safety critical roles, such as customer service staff.
Tabs/fields that can be activated for each role type:
- Medical rule
- T&C Annotation
- OTDR Number
- Driving Category
- Language
- Location
- Route
- Traction
- Incapacity
- License
- ID Card
- PTS Competence
- Competence Date
- Link Management
- Hours Tracker
- Home Station
Competence Date Rules
In ACMS, the following competence dates are recorded against candidates' roles:
- Original competence date: the date of the first time a candidate was deemed competent in the role at any TOC
- First competence date: the date of the first time a candidate was deemed competent in the role at the current TOC
- Current competence date: the date of the most recent summary assessment
ACMS calculates the expiry date of a candidate's competence based on competence date rules which add a defined period of time (in months) dependent on the length between the original and first date and first and current dates.
Example:
PQA dispatcher:
- Original - First range = 0 to infinity
- First - Current range = 0 to 10 months
= 12 months of competence
Default dispatcher:
- Original - First range = 0 to infinity
- First - Current range = 10 months to infinity
= 36 months of competence
It may be that several competence date rules need to be applied to each role type. For example, for a driver role you may need to have competence date rules set up for PQA Year 1, PQA Year 2, Transferred Experienced PQA Year 1, Transferred Experienced PQA Year 2, Transferred Experienced, Experienced.
For roles which have a number of competence date rules, the easiest way to visualise whether there are any gaps is to create a chart like the one below.
In this example, the rules are as follows:
PQA Driver Year 1:
- Original - First range = 0 to 1 month
- First - Current range = 0 to 10 months
= 36 months of competence
Transferred Experienced PQA Year 1:
- Original - First range = 1 to 22 months
- First - Current range = 0 to 10 months
= 12 months of competence
Transferred Experienced Driver:
- Original - First range = 22 months to infinity
- First - Current range = 0 to 22 months
= 36 months of competence
Transferred PQA Year 2:
- Original - First range = 1 to 22 months
- First - Current range = 10 to 22 months
= 12 months of competence
Experienced Driver:
- Original - First range = 0 to infinity
- First - Current range = 22 to infinity
= 36 months of competence
The diagram highlights that there is a gap for those with a date original to first range of 0-1 and a first to current range of 10-22.
Competence Date Rules Video.mp4
Incapacities
Pre-defined list of reasons a person's work is restricted or that they are off role.
Examples:
- Long Term Sick
- Maternity Leave
- Light Duties
- COVID-19
Reasons for Leaving
Pre-defined list of reasons for candidates leaving a role.
Examples:
- Deceased
- Dismissed
- Retired
- Sabbatical
Driving Categories
Languages
Locations
Locations are used in a number of different places on the system; they can be activated as a field for particular roles, are used within incidents/investigations and added to waypoints within assessments.
Locations can be categorised into Location Types. Examples of location types set up for other customers include engineering depots, stations, junctions, signals and yard & sidings.
Routes and Traction
There are two ways in which routes and traction can be set up on ACMS:
- As route reference data
- As role resources
The two options require slightly different set up and the second option provides a bit more functionality e.g. approval workflow and expiry times.
- Routes
| Route Number | Line of Route | Main Route | Crew Plan Route Codes | Route Contents | |
|---|---|---|---|---|---|
| Description | Number | Description of the route | For main routes - shortened version of the line of route or same information in line of route For sub routes - the associated main route | Associated crew plan route codes | Type of route |
| Example | 01 | Portsmouth Harbour to London Waterloo via Guildford | Portsmouth Harbour to London Waterloo | C01 | Main route |
| 01a | Haslemere to Guildford | Portsmouth Harbour to London Waterloo via Guildford | C01a | Sub route |
Benefits
- Route records are already integrated into a number of different aspects of ACMS e.g. Links, Hours Tracker and SCWIDs.
- The associated Crew Plan codes are clearly displayed on the candidate dashboard.
Limitations
- There is currently no way of tracking expired routes which need to be re-signed. Development would be required to record lapsing date and implement expiry date rules.
- Route learning documentation cannot be directly associated with the route record. These files would need to continue to be uploaded to Candidate Data.
- There is no functional link between main and sub routes. Despite the ability to note which main route each sub route falls under, this has no implication on the system e.g. if a sub route becomes expired, the main route does not also automatically become expired.
2. Role Resources
Role resources have three levels; Resource Type, Resource Subtype and Resource. In order to build routes as resources the following format would be built:
| Resource Type | Resource Subtype | Resource | Resource Properties | |
|---|---|---|---|---|
| Description | Route | Used to record the route contents | Used to record each individual route | Created to record additional information about each route e.g. Crew Plan route codes |
| Example | Route | Main Route | Name - 01 Description - Portsmouth Harbour to London Waterloo via Guildford | Main Route Crew Plan route code |
Expiry times can be added to resources at either the subtype or resource level. An expiry date will be automatically generated by ACMS based on the expiry time set when the resource was created. Expired resources are highlighted red on the dashboard and can be tracked using reports.
Users are able to request a refresh on a resource by selecting the resource and then clicking on the Resource Admin button followed by Request Refresh. This will mark the resource as ‘Refresh Required’ and the candidate will need to update the executed date. Optionally, this can then be authorised or rejected by the manager.
If you do decide that approvals are required, you will need to add a new property to team types that are allowed to do this. If you go to Menu > Personnel > Team Type and open the type of team that is allowed to do this. You can add a new property:
- In Key, enter ‘RESOURCE’
- In value, enter ‘true’
This allows managers to view all of the resources to be approved or rejected on the resource authorise page.
Benefits
- An expiry time can be added to the resources either at the subtype or resource level. Expired resources will display as red on the candidate dashboard and can be tracked using pre-existing reports.
- Route Learning documentation can be uploaded against each resource record.
- Resources can be displayed on SCWIDs.
- There is an optional resource approval workflow which allows managers to either accept or reject resource refreshes.
Limitations
- Development will be required to make the resource properties visible from the candidate dashboard. This has been discussed with the development team and is not a difficult change. This has already been factored into the next release.
- Development will be required to set up a new SCWID error code which checks for a Resource Type = Route for certain roles before permitting a SCWID to be issued. Again, this has been factored into the next release.
Medicals
Different types of medicals can be recorded on ACMS. By default, the following are available:
General (Periodic) Medicals
General medicals can be passed or failed. Failures can result in early review dates and/or restrictions to duty.
All the rules for managing expiry dates, according to the person’s age and role (rules are different for drivers) are built into the system. These medicals take the rule change that came into effect with the European Driving License directive.
By default we have the following medical rule collections which can be applied to different role types:
| Age (Up to) | Period Added | |
|---|---|---|
| Driver | 53 54 -1 (over 54) | 3 2 1 |
Driver -1 Sets expiry to a day before the expiry date | 53 54 -1 | 3 2 1 |
Driver Birthday Ensures the next medical falls on the drivers 56th birthday if the calculated expiry date goes beyond this | 53 54 -1 | 3 2 1 |
Driver Birthday -1 Ensures the next medical falls on the day before the drivers 56th birthday | 53 54 -1 | 3 2 1 |
| Default | 39 49 59 64 -1 | 10 6 4 2 1 |
Review Medicals
These are related to General Medicals and can result in further review dates and restrictions.
Sight Medicals
These are for recording whether or not people need glasses or other sight aids.
Hearing Medicals
These are for recording whether or not people need hearing or other communication aids.
There is a facility to add custom medicals, for example, to support additional hearing tests for people working in a noisy environment.
It is possible to set up different medical results for each type. For each option we need to know whether the following is required:
- Status - pass/fail
- Restrictions - yes/no
- Review date - yes/no
- Return date - yes/no
- Doctor registration - yes/no
Assessment Reference Data
Conditions
Conditions are added to assessments within waypoints to log additional information about the assessment and possible training needs. For example, noting the different weather conditions and daylight and darkness.
Condition Type examples:
- Certificates and licences
- Weather
- Assessment methods
Condition examples:
- SCWID carried, train driver licence carried
- Darkness, daylight, icy, misty
Level Sets
The levels which candidates are assessed against. The level description and colour must be defined, as well as whether each level requires a comment from the assessor.
AssessTech default level set:
Overdue Authorisation Reasons
The pre-defined list of reasons which assessors can select from to request authorisation of overdue assessments. Reasons which are valid for a longer period of time (e.g. maternity leave) can be set up so that the assessments are excluded from CMS events.
Examples:
- Assessor not available (still to be done)
- Candidate not available (still to be done)
- Long Term Sick
- Maternity Leave
- Removed from safety critical work (medical reason)
Schedule Types
Schedule Types need to be set up before being assigned to a criteria set to form a schedule that can be added to candidates. Schedule Types are used to specify the number of assessments that need to occur within a schedule and when they each need to occur.
On ACMS 'periods' are defined as the window of opportunity in which an assessment should be completed.Each period has the following information:
- Offset - the number of days from the start of the schedule that the assessment window
- Number of days - the length of the period in days
As period lengths are measured in days rather than months, it is best to follow the sequence of 30, 30, 31 days to standardise the length of the months in a year.
Schedule Type Properties can be used to enable further configuration. For CMS schedules the most important things to remember are:
- 'Dashboard' field should be set to YES - this adds the schedule to the list of schedules which can be added to a candidate through the candidate dashboard
- 'CMS' field should be set to YES - this makes sure that any assessments associated with this schedule are included in CMS Events
Schedule Templates
In order to match each schedule type with the relevant criteria set, Schedule Templates must be created.
The schedule wizard guides you through the steps required to set up a new schedule template, this includes assigning different criteria units to each period. Only criteria sets in a 'Sealed' state can be used in Schedule Templates. It is not necessary to assign criteria units to the Summary period as the system will automatically pick up any un-assessed or review item criteria from throughout the schedule in this period.
Make sure to tick the Events box if you require assessments associated with the schedule to display in CMS Events.
Links
Links are also known as “turns” or shift patterns. They represent a set of things a person must be competent to do, in order to work in a particular place, at a particular time.
A Link is described on ACMS in the following terms:
Role (i.e. Driver / Guard)
List of Routes
List of Traction
Depot
You can assign people to Links and quickly assess their competence gap for working that Link.
Additionally, if learning times are entered against routes, then you can run reports to show total learning time for a person, to sign a particular link
Teams
Teams can be set up to model the relationship between various people in a flexible way. Teams have leaders and members. Membership can be constrained by role and organisation (depot and region). There are two levels to Team setup.
Firstly, a Team Type must be defined, for example:
- Competence Management Team
- Line Management Team
Then actual teams can be set up using the Team Types as templates. For example:
- Fred’s Competence Team
- Joe’s Management Team
Resources
This is a facility to add information about the resources, against which people typically hold competence.
- Locations are used as part of competence; dispatchers typically with sign locations.
- Routes and traction are typically signed by guards and drivers, as part of their competence.
- Other competencies can be built into the system, for example, Engineering tasks, Management competencies, etc.
Resources have expiry dates (optional) so you can control the need to do refresher training and/or ‘sign’ things on a regular basis.
Learning times can be added, to facilitate training gap reports, for individuals or groups.
Example:
Resource Type - Training Course → Resource Subtype - TOLO → Resource - TOLO competency
Licensing Reference Data
ID Cards
SCWIDs (or complementary certificates) can be set up for each role type on ACMS.
We have developed default reports for each role which replicate the three page folded paper certificate. The certificates display all of the required information as detailed in the ORR train driving licences and certificates regulations. If a TOC requests the inclusion of additional information we can create bespoke certificate reports to meet the requirements.
IMAGE OF SCWID
Before an ID card is issued, ACMS checks that a candidate has the required information in order for their certificate to be valid. The error codes are configurable for each role, for example, ACMS will check that a Driver has assigned driving categories before an ID card is issued but the same error check will not be applied for Guards. Below is a link to a spreadsheet which can be used to detail the required error codes for each role.
VIDEO OF ADDING/ISSUING SCWID
Cab Passes
We can also create different cab passes on your system which are issued in the same way as SCWIDs with the additional of an extra approval process. Error checks can also be applied to cab passes.
VIDEO OF CAB PASS APPROVAL
Example:
Incident Reference Data
Cause Set
The list of causes which can be attributed to an incident. A bespoke cause set can be created, however typically we follow the standards outlined in the RIS-3119-TOM.
It's possible to make certain causes mandatory for each investigation by setting up 'Required' root folders. Different causes can be set up to also require an assigned respondent. For example, if verbal communication is identified as a cause of an incident then a respondent can be assigned, however this is not the case for an environmental cause.
Incident Category
Categories can be set up to categorise different incident types. Required information is defined at this level, as well as the necessary cause set.
Note: investigator duties are enabled based on categories e.g. you can restrict which investigations a user can be assigned as a Lead investigator for based on incident category.
Incident Type
A complete list of any incident that will be investigated on ACMS. Incident and respondent properties are assigned at this level.
Incident Property Type
Incident properties are the fields used to collect the information necessary to inform each investigation. Typically we replicate the fields used on pre-existing investigation forms.
There are a number of different property types - text, number, list, date, time, datetime.
It's not yet possible to make certain properties mandatory, however it's the responsibility of the DCP to ensure that all of the required information has been collected before an investigation is closed.
Incident Respondent Property Type
Respondent properties are properties that are associated with individuals rather than the incident as a whole. For example, different drugs and alcohol test results may need to recorded for each respondent.
Investigation Type
Different types of investigations can be set up and assigned to incident categories based on incident severity. A number of different things are defined at this level:
- Investigation length (days)
- Default report type (upload/generate)
- Incident category
- Same lead and DCP (yes/no)
Recommendation Category
Recommendations that derive as a consequence of an investigation can be categorised into different types based on a pre-defined list. For example,
This is an optional feature.
Remit Item Type
Remits can be set up so that investigators can add them to investigations. Remits can be locked or unlocked. Unlocked remits are editable by investigators, for example to add information specific to the investigation in question e.g. the name of the Lead investigator.