Sociologi. Service. Företagsorganisation och företagsledning. Administration. Transport Administration

Kommittébeteckning: SIS/TK 451 (Finansiella system)
Källa: ISO
Svarsdatum: den 30 dec 2018
Se merSe mindre
 

The development of a Financial Instrument Global Identifier originated out of the recognition that chaos theory has

nothing on the complexity generated everyday by the millions-perhaps billions-of security transactions that cross trading

floors, clearinghouses, and exchanges all over the world. Almost every aspect of securities management is based on

closed systems that use proprietary identifiers that are privately owned and licensed. Closing each deal is as much an

exercise in translation as it is in transaction processing, as traders, investors, and brokers wrestle with multiple proprietary

formats to determine what a security is, who owns it, how much it is worth, and when the deal should be closed. It

introduces a tremendous amount of friction into the trade lifecycle and creates opaqueness where clarity is sought. In

addition, the use of proprietary identifiers adds significant cost and overhead when users wish to integrate data from

disparate sources or migrate to a different market data system.

The evolution of advanced symbologies has helped the securities industry grow, but the limitations and costs imposed by

the closed systems have become more apparent as companies and institutions continue to integrate operations on a global

scale. Proprietary symbology now stands as one of the most significant barriers to increased efficiency and innovation in

an industry that sorely needs it. Moreover, the lack of common identifiers is a key roadblock to achieving the holy grail

of straight-through processing (STP).

Points of Note:

Licensing fees require firms to pay for each symbol system they use. International firms bear an especially heavy burden,

because they often have to license several symbologies in order to manage trading operations in several countries.

Restrictions imposed by proprietary symbologies prevent companies from easily mapping one set of codes to another.

This hinders integration of market data from diverse sources as well as efforts to automate trade and settlement activities.

Market data consumers who adopt proprietary symbols for use in their own systems must not only pay licensing fees, but

such symbols also lead to significant future costs associated with efforts to connect to emerging trading systems.

Proprietary trading environments may have worked well for years; but they are a byproduct of a time when data systems

operated largely as islands that did not have to interoperate with other systems.

Current trends dictate a different approach. Markets, customers, and governments are demanding greater connectivity,

transparency, and efficiency. What’s more, the openness of Internet-based systems has profoundly altered the way

businesses-and individuals-collect, manage, and share information. Thus, in addition to new regulations that demand

clarity and accountability, the move to open symbology is being driven by growing investor and institutional demands.

Adopting an open system of shared symbology establishes the foundation for a tremendous leap forward in the efficient

trade and settlement of securities as well as data management and reporting of financial instruments more generally.

Such a system will allow firms and technology service providers to shift resources from laborious, inefficient processes to

new investments in tools and products that will better serve clients.

An open system answers the call for greater transparency. Eliminating the need to remove proprietary IDs and re-map

financial instruments will greatly simplify the steps needed to migrate between market data platforms and trading

systems. Availability of a central symbology reference will facilitate mapping between users’ internal systems and create

opportunities for integration and automation of the global enterprise. This is to say that this standard represents a novel

solution in the market that is not currently covered by other identifiers currently in circulation.

This specification lays out the details of the Financial Instrument Global Identifier across two dimensions:

1. The specification of the structure of the Global Identifier itself—what is/is not valid as a Global Identifier and how a

Global Identifier is constructed and validated.

2. An ontological model specifying the relationship between the Global Identifier and other closely related information.

This International Standard has been created with the clear understanding that a published interface for creating identifiers

and linking together relevant parties, e.g., Certified Providers or the Registration Authority, through the use of technology

is a critical part of the operationalization of this standard. While high level descriptions of the various types of

organizations that need to be involved as well as high level descriptions of the interactions between such organizations

has been included in this International Standard, they are included on the understanding that there will need to be a

subsequent standard produced that details the necessary technical infrastructures and service level agreements for all

participating organizations. To be clear, the technical specification of those services and service level agreements is out of

scope for this document.

Global Identifier concepts are documented using two forms of definition:

1. A structured ontology specification of the concept, and its relationships to others, represented using the Web

Ontology Language (OWL), in the form of (a) RDF/XML serialized OWL, (b) ODM (Ontology Definition

Metamodel)-compliant ODM XMI, and (c) ODM-compliant UML XMI.

2. Natural language definitions which represent the concepts in natural language using the vocabulary of the finance

industry.

Two controlled vocabularies in rdf format, one specifying the list of possible values for security types, one specifying the

list of possible values for pricing sources. These lists are subject to growth over time as new security types are either

invented or incorporated into FIGI and as new pricing sources are taken into account.

This International Standard covers both the content of the models, and the underlying architecture employed for

producing and presenting the model.

This model is developed from a previously existing infrastructure that is currently active and had issued in excess of 150

million FIGI-compliant identifiers to date. The currently issued identifiers are freely available on a web site and through

data files and are delivered upon request in bulk on a daily basis to interested parties. The purpose of this International

Standard, however is to specify the structure of the Identifier itself and its relationship to key information elements rather

than to specify the technology and related interfaces used to generate, access, and manage the identifiers.

 

Kommittébeteckning: SIS/TK 303 (IT-system och IT-tjänster)
Källa: ISO
Svarsdatum: den 6 jan 2019
Se merSe mindre
 

1.1 General

This document provides guidance on the application of an SMS based on ISO/IEC 20000-1. It provides examples and recommendations with examples to enable organizations to interpret and apply ISO/IEC 20000-1, including references to other parts of ISO/IEC 20000 and other relevant standards.

Figure 1 illustrates an SMS with the clause content of ISO/IEC 20000-1. It does not represent a structural hierarchy, sequence, or authority levels. It shows that the guidance for Clause 8, Operation of the SMS, has been split into sub-clauses to reflect the service lifecycle.

The structure of clauses is intended to provide a coherent presentation of requirements, rather than a model for documenting an organization’s policies, objectives, and processes. Each organization can choose how to combine the requirements into processes. The relationship between each organization and its customers, users, and other interested parties influences how the processes are implemented. However, 179 an SMS as designed by an organization cannot exclude any of the requirements specified in ISO/IEC 20000-1.

The term ‘service’ as used in this document refers to the services in the scope of the SMS. The term ‘organization’ as used in this document refers to the organization in the scope of the SMS. The organization manages and delivers services to customers and can also be referred to as a service provider. Any use of the terms ‘service’ or ’organization’ with a different intent is distinguished clearly in this document. It should be noted that the organization in the scope of the SMS can be part of a larger organization, for example an IT department of a large corporation. The term ‘delivered’, as used in this document, can be interpreted as all of the service lifecycle activities that are performed in addition to daily operational activities. Service lifecycle activities include planning, design, transition, and improvement.

1.2 Application

The guidance in this document is generic and is intended to be applicable to any organization applying an SMS, regardless of the organization's type or size, or the nature of the services delivered.

The service provider is accountable for the SMS and therefore cannot ask another party to fulfill the requirements of Clauses 4 and 5 of ISO/IEC 20000-1. For example, the organization cannot ask another party to provide the top management and demonstrate top management commitment or to demonstrate the control of parties involved in the service lifecycle.

Some activities in Clauses 4 and 5 may be performed by another party under the management of the organization. For example, organizations can engage other parties to conduct internal audits on their behalf. Another example is when an organization asks another party to create the initial service management plan. The plan, once created and agreed, is the direct responsibility of and is maintained by the organization. In these examples, the organization is using other parties for specific short-term activities. The organization has accountability, authorities, and responsibilities for the SMS. The organization can therefore demonstrate evidence of fulfilling all of the requirements of Clauses 4 and 5 of ISO/IEC 20000-1.

For clauses 6 – 10 of ISO/IEC 20000-1, an organization can show evidence of meeting all of the requirements itself. Alternatively, an organization can show evidence of retaining accountability for the requirements when other parties are involved in meeting the requirements in Clauses 6 to 10 of ISO/IEC 20000-1. Control of other parties involved in the service lifecycle should be demonstrated by the organization (see 8.2.3). For example, the organization can demonstrate evidence of controls for another party who is providing infrastructure service components or operating the service desk including the incident management process.

The organization cannot demonstrate conformity to the requirements in ISO/IEC 20000-1 if other parties are used to provide or operate all services, service components or processes within the scope of the SMS. However, if other parties provide or operate only some of the services, service components, or processes, the organization can normally demonstrate evidence of meeting the requirements specified in ISO/IEC 20000-1.

The scope of this document excludes the specification of products or tools. However, ISO/IEC 20000-1 and this document can be used to help with the development or acquisition of products or tools that support the operation of an SMS.

1.3 Structure

This document follows the clauses in ISO/IEC 20000-1 and, from clause 4 onwards, provides three sections per clause or sub-clause:

a) Required activities: a summary of the activities required by this clause in ISO/IEC 20000-1—note that this does not replicate the requirement statements in ISO/IEC 20000-1 or add new requirements, but simply describes the activities;

b) Explanation: an explanation of the purpose of the clause and practical guidance on clause contents, including examples and recommendations with examples on how to implement the requirements of ISO/IEC 20000-1;

c) Other information: guidance on roles and responsibilities and on documented information supporting the implementation of an SMS. Further relevant information may also be included.

Kommittébeteckning: SIS/TK 303 (IT-system och IT-tjänster)
Källa: ISO
Svarsdatum: den 6 jan 2019
Se merSe mindre
 

This document includes guidance on the scope definition and applicability to the requirements specified in ISO/IEC 20000-1.

This document can assist in establishing whether ISO/IEC 20000-1 is applicable to an organization’s circumstances. It illustrates how the scope of an SMS can be defined, irrespective of whether the organization has experience of defining the scope of other management systems.

The guidance in this document can assist an organization in planning and preparing for a conformity assessment against ISO/IEC 20000-1.

Annex A contains examples of possible scope statements for an SMS. The examples given use a series of scenarios for organizations ranging from very simple to very complex supply chains.

This document can be used by personnel responsible for planning the implementation of an SMS, as well as assessors and consultants. It supplements the guidance on the application of an SMS given in ISO/IEC 20000-2.

Requirements for bodies providing audit and certification of an SMS can be found in ISO/IEC 20000-6:2017 which recommends the use of this document.

Kommittébeteckning: SIS/TK 289 (Gassystem)
Källa: ISO
Svarsdatum: den 7 jan 2019
Se merSe mindre
 

This document specifies the technical delivery conditions for bends made by the cold bending process for use in pipeline transportation systems for the petroleum and natural gas industries as defined in ISO 13623.

This document is applicable to cold bends made from seamless and welded pipe of unalloyed or low-alloy steels.

NOTE These are typically C-Mn steels or low-alloy steels that are appropriate for the corresponding level and grade of line pipe in accordance with ISO 3183.

This document specifies the requirements for the manufacture of two product specification levels (PSLs) of cold bends corresponding to product specification levels given for pipe in ISO 3183.

This document is not applicable to the selection of the cold bend product specification level. It is the responsibility of the purchaser to specify the PSL, based upon the intended use and design requirements; see also ISO 3183, Introduction.

Cold bending process shall not be used for bend radius less than 5 xOD

This document is not applicable to field cold bends and pipeline bends made by other manufacturing processes.

Kommittébeteckning: SIS/TK 450 (IT-standarder för Lärande)
Källa: ISO
Svarsdatum: den 8 jan 2019
Se merSe mindre
 

1.1.1 Scope of 24751

ISO/IEC 24751 is a multi-part standard that defines an AccessForAll framework to enable: 

•Individuals to discover, explore, refine, prioritize and request their personally unique preferences, for a given context, and

•AccessForAll services to satisfy the individual preferences by delivering a match (e.g, finding, assembling, developing, recruiting or using other strategies to deliver products,services, configurations or environments that match the preferences [herein referred to as AfA resources])

AccessForAll is in large part motivated by the goal of addressing currently unmet or poorly met preferences (where the term ‘preferences’ encompasses the range from critical needs to preferences). This goal is in part satisfied by registries, which are open to any individual or organization, to register possible preference concepts (as AccessForAll Preference Concepts), including concepts associated with unanticipated, emerging or new preferences. These registered AccessForAll Preference Concepts might then be used to express individual preferences within a broad diversity of AccessForAll implementing services. An AccessForAll Concept Registry is intended to register possible preference concepts; it is not used for individuals to declare or store personal preferences or personal preference sets (AfA Preference Statement), this is achieved through AccessForAll services that support discovery, exploration, refinement, prioritization and matching of Individual Preference Statements. (An AccessForAll Preference Concept might itself be able to represent a preference or it may require qualification and/or combination with other  preference concepts to form a preference through an AfA Preference Statement).

1.1.2 Future Parts

This International Standard is designed to accommodate developments in technology and implementations and supports the addition of more parts in the future.

1.2 Scope of Part 1 of 24751

Part 1 specifies the basic principles of an AccessForAll approach and the specifications for AccessForAll (AfA) registries.

This part defines:

•a framework and basic principles to support matching of individually unique preferences (that may vary according to the context, including the user goal) to resources that satisfy the preferences.

•specifications for AccessForAll (AfA) registries to register AfA Preference Concepts

In order to make it easier for users and developers to understand and use AfA Preference Concepts, this part supports registration of multiple names and descriptions for a given AfA Preference Concept. It aims to enable users, developers, and others to use their chosen names and descriptions, in their chosen natural language, and yet have them interoperate within many systems.

AccessForAll Preference Concepts will be used by AccessForAll services to:

•enable individuals to create AfA Preference Statements (3.5) or requests, (this includes discovering, exploring, evaluating and refining an understanding of the preferences that work best for them in a given context to achieve a given goal),

•identify resources that match AfA preference concepts (including, but not limited to, through the application of resource metadata)

•match resources to personally declared AfA Preference Statements

Kommittébeteckning: SIS/TK 579 (Facility Management)
Källa: CEN
Svarsdatum: den 11 jan 2019
Se merSe mindre
 

This document provides a guideline how to measure, achieve and improve quality in FM. It gives complementary guidelines to EN ISO 9000, EN ISO 9001 and EN ISO 41012 within the framework of EN ISO 41011 and ISO/TR 41013 The standard provides a link into management methods and management theories.

This European Standard is applicable to:

— FM in public and private organizations;

— client organization and service provider relationships;

— full range of facility products or facility services;

— both types of service providers in FM (internal and external);

— all types of working environments (e.g. industrial, commercial, administration, military, healthcare etc.).

This document is applicable to business services (not consumer oriented).

This document does not:

— replace the quality management systems of the client organization;

— provide standard forms:

— for performance and quality management systems (delivering a quality management system);

— for defining requirements;

— for a measurement tool;

— for service level;

— apply to the certification of the quality system of Facility Management (covered by EN ISO 9001).

Kommittébeteckning: SIS/TK 579 (Facility Management)
Källa: CEN
Svarsdatum: den 11 jan 2019
Se merSe mindre
 

FM covers and integrates a very broad scope of processes, products / services, activities and facilities. The approach of this standard is to consider the added value provided to the primary activities by adopting a product perspective as recognized by the primary processes or core business in the organization. This standard therefore introduces the concept of standardized (classified) facility products.

The scope of this standard is to provide taxonomy for FM which includes:

— relevant interrelationships of elements and their structures in FM;

— definitions of terms and contents to standardize facility products which provide a basis for cross border trade, data management, cost allocation and benchmarking;

— a high level classification and hierarchical coding structure for the standardized facility products;

— expanding the basic FM model given in ISO 41011 by adding a time scale in the form of the quality cycle called PDCA (Plan, Do, Check, Act);

— a linkage to existing cost and facilities structures;

— alignment with the primary activities requirements.

Additional benefits from this standard are:

— Introducing a client rather than a specifically asset oriented view;

— Harmonization of different existing national structures (e.g. building cost codes) on an upper level relevant for the organization and its primary activities.

Kommittébeteckning: SIS/TK 579 (Facility Management)
Källa: CEN
Svarsdatum: den 11 jan 2019
Se merSe mindre
 

This document provides guidance to FM organisations on the development and improvement of their processes to support the primary processes.

This document also sets out basic principles, describes high-level generic FM processes, lists strategic, tactical and operational processes and provides examples of process workflows.

The document is written from a primary processes, demand perspective for an audience of all stakeholders in FM processes.

Kommittébeteckning: SIS/TK 579 (Facility Management)
Källa: CEN
Svarsdatum: den 11 jan 2019
Se merSe mindre
 

This document establishes a common basis for planning and design, area and space management, financial assessment, as well as a tool for benchmarking in the field of Facility Management.

This document covers area and space measurement for existing owned or leased buildings as well as buildings in state of planning or development.

This document presents a framework for measuring floor areas within buildings and areas outside of buildings. In addition, it contains clear terms and definitions as well as methods for measuring horizontal areas and volumes in buildings and/or parts of buildings, independent of their function.

Se merSe mindre
 

This document gives guidelines for how to process and resolve potential vulnerability information in a product or service.

This document is applicable to vendors involved in handling vulnerabilities.