Difference between revisions of "Coverage"
From RFF Wiki
(→Coverage Map) |
|||
| (8 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Overview == | == Overview == | ||
| + | [[file:2101127 ARCH Coverage SmallRU-Overview RFF.png|border|center|800px|Coverage Overview]] | ||
| − | + | == Type of RU partner == | |
| + | The terms "Small RU" or "Large RU" are 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). | |
| − | |||
| − | |||
| − | * Type A | + | * Type A -> [[Glossary]] |
| − | * Type B | + | * Type B -> [[Glossary]] |
| − | * Type C | + | * Type C -> [[Glossary]] |
| − | + | For Type A & B RU's we have planned dedicated workshops in which they can place their issues, remarks, questions and wishes concerning the Digital platforms. They are called [[Discovery Session]]s. | |
| − | |||
| − | == | + | == Coverage Map == |
| − | The actual state of data quality management matrix is available at [[ | + | * The actual state of integration is available at [[Coverage Map]]. |
| + | * The actual state of data quality management matrix is available at [[Coverage Map]]. | ||
Latest revision as of 22:49, 18 March 2021
Overview
Type of RU partner
The terms "Small RU" or "Large RU" are 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).
For Type A & B RU's we have planned dedicated workshops in which they can place their issues, remarks, questions and wishes concerning the Digital platforms. They are called Discovery Sessions.
Coverage Map
- The actual state of integration is available at Coverage Map.
- The actual state of data quality management matrix is available at Coverage Map.
