Difference between revisions of "Phase2 Iteration2"
(→C19 TrainOperation Requirements -> RU A/B type requirements) |
(→Results) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 35: | Line 35: | ||
The first step focus on identification and description of the KPIs to be measured. | The first step focus on identification and description of the KPIs to be measured. | ||
| − | * list in Excel [https://teams.microsoft.com/l/file/ | + | * list in Excel [https://teams.microsoft.com/l/file/3B6C5C7A-6509-4C6E-A9E3-11E81480ABE2?tenantId=ef588fbf-8705-4200-a1a6-3be9fc3bb45b&fileType=xlsx&objectUrl=https%3A%2F%2Fxrail.sharepoint.com%2Fsites%2FRFFDigitalPlatforms-Architecturefullteam%2FShared%20Documents%2FPhase%202%2FIterations%2FIteration3%2FReview%2F210128_KPI_H30_CN_V1.xlsx&baseUrl=https%3A%2F%2Fxrail.sharepoint.com%2Fsites%2FRFFDigitalPlatforms-Architecturefullteam&serviceName=teams&threadId=19:deda0f2b868c4f88ad034a8e9bf78fc1@thread.tacv2&groupId=364382c0-ae89-46c5-a6d5-05adcf2e5b53 H30 KPIs] |
* Roadmap in Powerpoint | * Roadmap in Powerpoint | ||
* Maintenance process in Powerpoint | * Maintenance process in Powerpoint | ||
| Line 46: | Line 46: | ||
* The second one affects the type of applied measurements. To start with only wagon related KPIs are measured. This needs to evolve to other types of information in H30, based on the learnings in the [[Data Maintenance]] process of H30. | * The second one affects the type of applied measurements. To start with only wagon related KPIs are measured. This needs to evolve to other types of information in H30, based on the learnings in the [[Data Maintenance]] process of H30. | ||
| − | + | ==== C76 Monitor Consignment Note KPI ==== | |
In this iteration we worked out three steps to monitor the CN data quality and its coverage. | In this iteration we worked out three steps to monitor the CN data quality and its coverage. | ||
* Identified CN KPIs | * Identified CN KPIs | ||
| Line 55: | Line 55: | ||
The first step focus on identification and description of the KPIs to be measured. | The first step focus on identification and description of the KPIs to be measured. | ||
| − | * [https://teams.microsoft.com/l/file/ | + | * [https://teams.microsoft.com/l/file/3B6C5C7A-6509-4C6E-A9E3-11E81480ABE2?tenantId=ef588fbf-8705-4200-a1a6-3be9fc3bb45b&fileType=xlsx&objectUrl=https%3A%2F%2Fxrail.sharepoint.com%2Fsites%2FRFFDigitalPlatforms-Architecturefullteam%2FShared%20Documents%2FPhase%202%2FIterations%2FIteration3%2FReview%2F210128_KPI_H30_CN_V1.xlsx&baseUrl=https%3A%2F%2Fxrail.sharepoint.com%2Fsites%2FRFFDigitalPlatforms-Architecturefullteam&serviceName=teams&threadId=19:deda0f2b868c4f88ad034a8e9bf78fc1@thread.tacv2&groupId=364382c0-ae89-46c5-a6d5-05adcf2e5b53 CN KPIs] |
* Roadmap in Powerpoint | * Roadmap in Powerpoint | ||
* Maintenance process in Powerpoint | * Maintenance process in Powerpoint | ||
| Line 66: | Line 66: | ||
* The second one relates to the type of traffic for which CN messages are sent. So far only CN messages for international transports are sent. To be able to measure the data quality also CN messages for domestic transports need to be sent. | * The second one relates to the type of traffic for which CN messages are sent. So far only CN messages for international transports are sent. To be able to measure the data quality also CN messages for domestic transports need to be sent. | ||
| − | + | ==== C14 Pilot for maintenance of WSM KPI ==== | |
Parallel to the review and acceptance of the WSM KPI definition the core team has launched the pilot for the maintenance process of the WSM KPI. | Parallel to the review and acceptance of the WSM KPI definition the core team has launched the pilot for the maintenance process of the WSM KPI. | ||
After the first sessions we can summerize that the pilot was launched successfully. | After the first sessions we can summerize that the pilot was launched successfully. | ||
| − | + | ==== C19 TrainOperation Requirements -> RU A/B type requirements ==== | |
In this task we had to enlarge the scope beyond TrainOperation and Consignment Note information. | In this task we had to enlarge the scope beyond TrainOperation and Consignment Note information. | ||
We have created a structure to learn about the "small" RUs situation and their needs. | We have created a structure to learn about the "small" RUs situation and their needs. | ||
| Line 85: | Line 85: | ||
* Register at MIRO to access the board used in the sessions | * Register at MIRO to access the board used in the sessions | ||
The material is available on [https://teams.microsoft.com/_#/files/Architecture?threadId=19%3A2ae0c3a808134862b280a79d6edb3cc4%40thread.tacv2&ctx=channel&context=BasicMaterial&rootfolder=%252Fsites%252FRFFDigitalplatforms%252FShared%2520Documents%252FEU%2520data%2520platforms%252FPhase%25202%252FRU%2520architecture%2520meetings%2520-%2520full%2520round%252FDiscoverySessions%252FBasicMaterial Basic Material for Discovery Sessions] | The material is available on [https://teams.microsoft.com/_#/files/Architecture?threadId=19%3A2ae0c3a808134862b280a79d6edb3cc4%40thread.tacv2&ctx=channel&context=BasicMaterial&rootfolder=%252Fsites%252FRFFDigitalplatforms%252FShared%2520Documents%252FEU%2520data%2520platforms%252FPhase%25202%252FRU%2520architecture%2520meetings%2520-%2520full%2520round%252FDiscoverySessions%252FBasicMaterial Basic Material for Discovery Sessions] | ||
| − | + | ===== Small RU ===== | |
The term Small RU is for our purpose too vage and may lead to different interpretations. Our distinction is focused on what type of IT the RU is using: | The term Small RU is for our purpose too vage and may lead to different interpretations. Our distinction is focused on what type of IT the RU is using: | ||
* Office and webbbased IT: The RU requires both external webbased and mobile clients and he needs a Office based integration. Some steps in the use cases are covered by manual interactions. He requires webbased or mobile Apps to enable him to participate in the common data transfer. | * Office and webbbased IT: The RU requires both external webbased and mobile clients and he needs a Office based integration. Some steps in the use cases are covered by manual interactions. He requires webbased or mobile Apps to enable him to participate in the common data transfer. | ||
| Line 104: | Line 104: | ||
==== Replan iterations 3 and 4 ==== | ==== Replan iterations 3 and 4 ==== | ||
| − | During this iteration the initial iteration planning for Q1 was discussed with the RFF steering | + | During this iteration the initial iteration planning for Q1 was discussed with the RFF steering committee. They accepted the general planning and raised the wish to start |
* to work on the SmartServices in Q1 and | * to work on the SmartServices in Q1 and | ||
* to put more focus on Coverage. | * to put more focus on Coverage. | ||
| Line 112: | Line 112: | ||
==== Plan iterations 5 to 8 ==== | ==== Plan iterations 5 to 8 ==== | ||
| − | During this iteration the initial iteration planning for Q2 was prepared for the alignment and planning with the RFF steering | + | During this iteration the initial iteration planning for Q2 was prepared for the alignment and planning with the RFF steering committee. The planning is available at |
[[File:Q2_Planning_210226.png|border|center|800px|Q2 Planning]]. | [[File:Q2_Planning_210226.png|border|center|800px|Q2 Planning]]. | ||
Latest revision as of 08:45, 4 March 2021
The Phase 2 works in iterations. See setup of the Architecture stream.
Contents
Iteration 2
The second iteration lasts from 11.February to 4.March.
Topics
Capabilities
In this iteration four of the top most ranked capabilites from the shopping list are treated in this second iteration. Also tasks created during the work in the first ieteration are tackled here.
C66 Monitor H30 quality
The aim is to define the KPIs for the Hermes 30 Message flow. For details of the Wagon Status domain please read Domain Train Preparation. The task includes the definition and description of the KPI. It also encompasses the grouping of the found KPIs into work packages and the setup of a roadmap for implementation. In the next step the exact formula for the its calculation, the targeted level for the data quality and the report frequency are tackled and aligned with the participating RUs in the ARCH stream.
C76 Monitor Consignment Note KPI
The aim is to define the KPIs for the Consignment Note Message flow. For details of the Consignment Note domain please read Domain Train Preparation. The task includes the definition and description of the KPI. It also encompasses the grouping of the found KPIs into work packages and the setup of a roadmap for implementation. In the next step the exact formula for the its calculation, the targeted level for the data quality and the report frequency are tackled and aligned with the participating RUs in the ARCH stream.
C14 Pilot for maintenance of WSM KPI
Parallel to the review and acceptance of the WSM KPI definition the core team will launch the pilot for the maintenance process of the WSM KPI.
C19 TrainOperation Requirements
To simplify the access for small RU's to participate in a train run the operation of a train should be backed up by providing information before and during the train run, assist in the preparation and operation of the train and include the small RU in the information and management loop together with the (bigger) partner.
Results
C66 Monitor H30 quality
In this iteration we worked out three steps to monitor the H30 data quality and its coverage.
- Identified Hermes 30 KPIs
- Defined measurement points
- Prioritized KPIs
- Roadmap KPIs
The first step focus on identification and description of the KPIs to be measured.
- list in Excel H30 KPIs
- Roadmap in Powerpoint
- Maintenance process in Powerpoint
The overview of the KPIs, grouped in work packages, can be seen here.
We have detected two open issues:
- The first one relates to the Coverage Map. Only a handfull of RU's are sending copies of H30 to RailData. To be able to measure the data quality all RU's need to send in a copy of their H30 messages.
- The second one affects the type of applied measurements. To start with only wagon related KPIs are measured. This needs to evolve to other types of information in H30, based on the learnings in the Data Maintenance process of H30.
C76 Monitor Consignment Note KPI
In this iteration we worked out three steps to monitor the CN data quality and its coverage.
- Identified CN KPIs
- Defined measurement points
- Prioritized KPIs
- Roadmap KPIs
The first step focus on identification and description of the KPIs to be measured.
- CN KPIs
- Roadmap in Powerpoint
- Maintenance process in Powerpoint
The overview of the KPIs, grouped in work packages, can be seen here.
We have detected two open issues:
- The first one relates to the Coverage Map. Only the RailData member RU's are sending CN to RailData. To be able to measure the data quality all RU's need to send in a copy of their CN messages.
- The second one relates to the type of traffic for which CN messages are sent. So far only CN messages for international transports are sent. To be able to measure the data quality also CN messages for domestic transports need to be sent.
C14 Pilot for maintenance of WSM KPI
Parallel to the review and acceptance of the WSM KPI definition the core team has launched the pilot for the maintenance process of the WSM KPI. After the first sessions we can summerize that the pilot was launched successfully.
C19 TrainOperation Requirements -> RU A/B type requirements
In this task we had to enlarge the scope beyond TrainOperation and Consignment Note information. We have created a structure to learn about the "small" RUs situation and their needs. For that we will organize sessions where we work out the (IT and process) surrounding in which those RUs operate. The actual planning foresees to have discovery sessions regularly every two weeks in the next months:
The content discussed in those sessions encompasses the topics a smaller RU is faced with:
With this structure in place we will plan the discovery sessions for the next weeks. Please help us and publish these sesssions internally in your company to attract many interested parties. The target group are type "A" and "B" RU (see below). The preparation consists of three steps:
- Send a mail to RFF ARCH group
- Read the RFF introduciton slides and the entry questions in the questionnaire to acquaint yourself to the topics
- Register at MIRO to access the board used in the sessions
The material is available on Basic Material for Discovery Sessions
Small RU
The term Small RU is for our purpose too vage and may lead to different interpretations. Our distinction is focused on what type of IT the RU is using:
- Office and webbbased IT: The RU requires both external webbased and mobile clients and he needs a Office based integration. Some steps in the use cases are covered by manual interactions. He requires webbased or mobile Apps to enable him to participate in the common data transfer.
- Lean, off-the-shelf IT: The RU runs off-the-shelf software with "standard" apdapters for different services. Some advanced use cases are not supported by his systems and are (semi)- manually. He is looking for suitable interfaces to conntect to the off-the-shelf adapters.
- Extensive, tailor made IT: The RU runs tailor made software adpated to his specific needs. This can be based on off-the-shelf software too which was tailored to an importent degree according to his needs. He wants to evolve his IT landscape frictionless and secure the return on his investments. The volume of transactions don't allow (semi)- manual processes. He looks for external services that helps him to streamline his processes internally and to innovate the next service types.
This leads to different requirements for digital platforms. Therefor we differentiate in our context between the three RU types:
- App based RU (web, mobile, office)
- Basic API oriented RU (based on sector standards)
- Comprehensive service oriented RU (full service context)
This is a model to distinct between the different needs of such a schematic sketched RU. In real life a RU may combine several of those types. He may run a tailor made, extensive commercial system (so type C RU). In production he plans with webbased tools (type A RU) and he operates his transports with an off-the-shelf product (type B RU).
Introduce ticket system
To support the ARCH stream in planning and managing the different tasks UTrack as ticketing system, the installation is operated by Xrail, is prepared and configured. We introduce it in the iteration session to the full team to enable all to manage their tickets. After this the tasks for the full team members are managed and tracked over the UTrack tickets.
Replan iterations 3 and 4
During this iteration the initial iteration planning for Q1 was discussed with the RFF steering committee. They accepted the general planning and raised the wish to start
- to work on the SmartServices in Q1 and
- to put more focus on Coverage.
Therfore we replanned iteration 3 and 4 slightly to include this two topics. The planning is available at
The tasks in those iterations are taken from the shopping list.
Plan iterations 5 to 8
During this iteration the initial iteration planning for Q2 was prepared for the alignment and planning with the RFF steering committee. The planning is available at
