Requirement: Modeling Language

LearnPAd Meta Model

Purpose:

1. BP-Models: Content references

Documents, artifacts and data object related to the process should be referenced by business process model elements. A documents flow is particularly relevant in Public Administrations, in most of the case documents are the main input-output. Learning based on business process means also know what are the documents involved in the different tasks.

2. Roles and Profile

The learning system should support different learning profiles. People that will learn based on the proposed solution could be different in term of process execution expertise, so it is important to consider that different abstraction levels of the seme Business Process should be considered.

3. BP-Modelling Standards

Modeling tools and learning platform should use standards when available. These standards are suitable to create consistency.

4. BP-Modelling Method: BPMN usage

The BP shall be defined according to specific standards. The usage of standards might help in the definition of models with a uniform appearance.

5. BP-Models: Global and Local Views

The system shall support the definition of a relationship between the global BP view and the local BP view.

6. Custom Business Process Metamodel Extensions

The system shall support tailoring standard business process metamodel for specific needs of a particular PA office by adding custom properties for selected business process model elements.
BPMN provides a standard set of properties for process model elements. However, different organizations will have different specific needs for augmenting generic process information with additional information such as auditing logs, confidentiality levels, etc. It is impossible to foresee everything that might be needed by in different PAs. Therefore the system shall enable tailoring business process metamodel with specific extended properties, which are not part of BPMN or another standard business process modeling language. Managing information for these properties shall be supported in textual knowledge base system with minimal configuration effort. 

7. Distinction Between Read-Only and Editable Content

The system shall enable specifying which information can be changed/modified in the textual business process knowledge base and which cannot be changed and must be kept as provided from the business process model. 
Some of the knowledge information will be derived from model and should only be modified there by appropriate people to ensure proper governance and compliance. Also, it might be that specific information needs to be changed only in the model, e.g. process ID and name probably cannot be changed, while its description, links to external documents and similar information can be modified in a knowledge base.

8. Business Process Model in Multiple Abstraction Levels

The system should support multiple abstraction levels of business process knowledge representation. Managers will need higher level process models that the workers who need to perform atomic tasks.

9. Content Document Modelling

The meta model used by the PA's must have a way of  providing direct pointers to relevant documents. Based on the nature of the UNICAM use case - it is utmost important to be able to define these pointers within the process.

10. BP-Modelling Processing: Performance monitoring

The modelling language (and corresponding platform components) should allow some sort of performance monitoring model to track/monitor the success. It is important to define KPI's that should be monitored. This can be achieved on the ML level by providing applicable model types and mechanisms to monitor and evaluate the current state of the system. A viable approach would be to adopt the BSC.

11. Learning Experience Profiling

The system should be able to profile learning experience. The possibility to profile the knowledge of a civil servant permits to better organize its learning experience, providing and suggesting contents that are actually interesting for the learner.

12. Learning Goals for Process Model

The system should support the definition of learning needs for processes. If a BP model explicitly relates to its learning goals the learning experience of the civil servant can be better customized.

13. Learners Knowledge Assessment

The system shall enable assessing learners' knowledge based on questionnaires that are derived from model-based and text-based knowledge about business processes. DoW states that Learn PAd will provide knowledge assessment functionality.

14. KPI-Models: Subjective and objective

The KPI sub-system should support both subjective and objective metrics. Objective metrics are useful in expressing KPI that represent the actual status of the system, a learning process, a contributor, or a learner. While, subjective metrics are more useful when the goal is to evaluate how they are perceived by the others.

15. KPI-Models: Quality Metrics

The system must allow to define KPIs and how they are calculated. A KPI is usually defined by a metric that has a value and is calculated by a more or less complex business logic. The system must thus allow the user (in an authorized role) to define both the name and the type of the KPI, but also the actual business logic that is able to compute it.  In fact, available and interesting KPI may vary over time and between different administrations. The system must allow to tailor LearnPAd KPI to the requirements of the users that will use it. An extensible mechanism for introducing KPI will make LearnPAd more attractive.

16. Content Role Based Views

The system should provide the possibility to switch views for specific viewpoints. For example an expert business user might be interested on other aspects or different level of granularity than a novice user. Providing personalized, or role-based, views on content could reduce complexity and enhance user friendliness.

17. KPI-Models: Scorecard

The system should provide a formalism (simiar to e.g. a Balanced Scorecard) to define/model organizational goals and derive learning goals from them.  Afterwards, the system should be able to explain how a learning goal depends on organisational goals.
Ultimately, the learning success will have to be measured by the degree to which the process execution contributes to the organisational success. Achieving a learning goal that has no connection to the organisational goals/strategy is worthless - therefore, we need to make the connection visible in order to motivate PA employees to achieve the learning goals.

18. Roles and Profile

The system should be able to model profiles for potential customer of the specific PA. Having a profile of the final user that will refer to the BP, could help learners in having a better comprehension about the overall process the BP models.

19. Learner Profiles

The system shall deal with different type of learners (PA, SME, etc, ...). Therefore it is necessary to adapt the learning approach to each single group of target, because learning by doing is something that must fit with different kind of organizations and because each group of target has a different point of view of the same process.

20. Learning Categories

The system should support categories of learning sessions (i.e. optional/mandatory/recommended). Such categorization could help learners in organize their tasks.

21. KPI-Model: Learning Assessment

The system must support KPI for assessing learners and learning processes. Key Performance Indicators represent an efficient means for evaluating applications, services, and even learners. In each case we may state a list of threshold values that represent the desired values. After monitoring the enacted processes and the learners behaviour the system and more precisely the governance part must be able to assign specific marks and notations.

22. BP-Model Hierarchical View Derivation

The system shall verify derivation of properties from higher to lower level of business processes and vice-versa.
The goal is verifying high-level models and ensure that also low-level models that are derived from the high-level model are verified because they inherit the same structure. Some global properties (e.g., AG properties) that hold on the global model normally hold also for the derived refined model, if compliance is ensured with the parent model. Other properties (e.g., Existence properties) shall be verified also on the local model. The goal is to reduce the verification effort, and verify most of the properties on the high level view.

23. KPI-Models to assess Model-Quality

Quality attributes SHALL be defined for both wiki pages and business processes. This requirement is in line with the DOW. In particular, according to the WP4 description we will have to define mechanisms for assessing the quality of both models and contents. Since they are different kinds of artifacts, it will be necessary to understand what are the quality attributes that make sense for wiki pages and those for business processes.

24. Expert Roster 

The system shall have the ability to suggest specific experts to specific learners. Experts can give advices to learners for a specific PA procedure, but also for understanding a model associated to a specific procedure.

25. Business Process Models in Multiple Levels of Detail

The system should support multiple levels of detail for a business process and an easy navigation between levels of detail. It is a common practice to represent complex business processes in several levels of detail in order to deal properly with the complexity. Public administration processes will typically be rather complex and having just a single level of details will be not be a suitable solution.

26. Roles and Expert Levels

The modelling language/method must allow the definition of user skills. It is important to have a vehicle where we will define the skill profiles of the users of the system as this is relevant to decide on how to provide them with content (type), how to adapt the delivery channels, etc.

Scope:

The scope of the LearnPAd metamodels describe the modeling language, that provides the metamodels of the following six aspects:

  • Process 
  • Organizational Structure 
  • Document and Knowledge 
  • Key Performance Indicator 
  • Business Motivation 
  • Case Management
Target System:
ADOxx 1.3UL1

Functional Requirements Specification:

The system shall provide a process-driven modelling toolkit for public administration integrated with collaborative tools and services of the project platform with the following modeltypes:

  • Process Metamodel
  • Document and Knowledge Metamodel
  • Organizational Structure Metamodel
  • Key Performance Indicator Metamodel
  • Business Motivation Metamodel
  • Case Metamodel
Non-Functional Requirements Specification:

N/A

Average (0 Votes)
The average rating is 0.0 stars out of 5.
No comments yet. Be the first.