natgillin/translations-raw huggingface dataset:
(3) The IT Project Directorate is organised into five domains. 
(3) Tietotekniikkahankkeiden osasto on jaettu viiteen alaan.
Each domain is in charge of projects initiated by different Business Areas. 
Kukin ala on vastuussa EKP:n eri toiminnallisten yksiköiden käynnistämistä hankkeista.
(4) Excluded from the POCP are small tasks, projects which are either conducted within one Business Area or not requiring any IT solutions, or IT infrastructure tasks with low volume of testing, low degree of innovation, low organisational impact which do not add any new service. 
(4) Hankkeen organisointi-ja valvontamenettelyä ei sovelleta pieniin tehtäviin; hankkeisiin, joita toteuttaa ainoastaan yksi EKP:n toiminnallinen yksikkö tai jotka eivät edellytä käyttöjärjestelmiä, tai tietotekniikan infrastruktuuritehtäviin, joiden testauksen määrä, innovaatioaste tai organisatorinen vaikutus on vähäinen tai jotka eivät luo uutta palvelua.
The projects selected for detailed audit by the Court were all within the remit of the POCP. 
Kaikki tilintarkastustuomioistuimen yksityiskohtaiseen tarkastukseen valitut hankkeet kuuluivat hankkeen organisointi-ja valvontamenettelyn soveltamisalaan.
EN C 32/6 Official Journal of the European Union 9.2.2010 23. 
C 32/6 Euroopan unionin virallinen lehti 9.2.2010 FI 23.
A project’s lifecycle, as defined in the POCP, sets the structure for effective control over projects by dividing the project lifecycle into logical phases and by setting precise decision-making points (see Diagram 1). 
Hankkeenorganisointi-javalvontamenettelyjäkäsittelevänasiakirjanmukaisestihankkeenelinkaari muodostaa rakenteen hankkeiden vaikuttavaa valvontaa varten siten, että hankkeen elinkaari jaetaan loo­ gisiin vaiheisiin ja siinä asetetaan selkeät päätöksentekohetket (ks. kaavio 1).
A comparison of the POCP with the PMBOK showed that the POCP was to a large extent in line with this best practice. 
Asiakirjan vertailu hankehal­ linnointitietojen kanssa osoitti, että asiakirja oli pitkälti yhdenmukainen tämän parhaan käytännön kanssa.
Two areas in which the POCP could be improved include: stakeholder analysis and post-assessment of the project’s impact. 
Hankkeen organisointi-ja valvontamenettelyjä voitaisiin parantaa seuraavalla kahdella alalla: sidosryhmien analysointi ja hankkeen vaikutuksen jälkiarviointi.
The current weaknesses and their impact are detailed in the following paragraphs. 
Nykyiset puutteet ja niiden vaikutukset on esitetty yksi­ tyiskohtaisesti seuraavissa kohdissa.
Diagram 1 — Project lifecycle phases Source: European Central Bank. 
Kaavio 1 – Hankkeen elinkaaren vaiheet Lähde: Euroopan keskuspankki.
ThePOCPdoesnotrequiretheformalpreparationanddocumentationofastakeholderanalysis.This means that the project team does not have to formally identify the stakeholders and determine their specific project requirements (1). 
Tämän vuoksi hanketiimin ei tarvitse muodollisesti yksilöidä sidosryhmiä eikä määritellä niiden erityisiä hankevaatimuksia (1).
The absence of the formal identification of all stakeholders and their needs could have a negative impact on the success of a project. 
Kaikkien sidosryhmien ja niiden tarpeiden muodollisesti yksilöimättä jättäminen saattaa haitata hankkeen onnistumista.
It should be noted that in the case of the specific projects examined, user needs were considered (see paragraphs 33 and 36). 
On syytä mainita, että tarkasteltujen hankkeiden kohdalla käyttäjien tarpeet oli otettu huomioon (ks. kohdat 33 ja 36).
Such an assessment would, amongst other things, provide a formal judgement on the achievement of the expected qualitative and quantitative benefits set out in the project approval documents and thereby help the planning of future projects (see paragraph 53). 
Hankkeentuloksiajavaikutuksiaeiarvioidajälkikäteen,joshankeonollutkäynnissätietynajan. Jälkiarvioinnilla voitaisiin kuitenkin muodostaa arvio siitä, onko hankkeen hyväksyntää koskevissa asiakir­ joissa asetetut odotetut laadullisesti ja määrällisesti ilmaistavat hyödyt saavutettu.
Allocation of responsibilities and decision-making structure 26. 
Vastuualueiden jako ja päätöksentekorakenne 26.
Toensurethatprojectsareimplementedefficientlyandeffectivelyitisnecessarytoestablisha framework for managing them setting out clear reporting lines and responsibilities of the bodies and functions involved in the process. 
Jottavoidaanvarmistuasiitä,ettähankkeitatoteutetaantehokkaastijavaikuttavasti,ontarpeenluoda hallintorakenne määrittelemällä prosessiin osallistuvien elinten ja tehtävien väliset selkeät raportointiketjut ja vastuualueet.
The POCP document established the organisational structure to be set up for the management of the ECB projects, including the roles and responsibilities as well as the composition of the relevant participating entities (see Diagram 2). 
Hankkeenorganisointi-javalvontamenettelyäkoskevassaasiakirjassaesitetäänorganisaatiorakenne, joka on luotava EKP:n hankkeiden hallinnointiin, ja siihen sisältyy lisäksi hankkeeseen osallistuvien tahojen tehtävät ja vastuualueet ja kyseisten tahojen rakenne (ks. kaavio 2).
(1) According to section 2.2 of the PMBOK, this is necessary in order to ‘ensure a successful project’. 
(1) Hankehallinnointitietojen 2 osan 2 kohdan mukaan tämä on hankkeen onnistumisen kannalta välttämätöntä.
In the project communications planning section 10.1 of the PMBOK it stated that ‘identifying the needs of the stakeholders and determining a suitable means of meeting those needs is an important factor for project success’. 
Hankehallinnointitietojen 10 osan 1 kohdassa – ”hankkeen tiedottamista koskeva suunnittelu” – mainitaan, että sidosryhmien tarpeiden yksilöinti ja niiden täyttämiseen soveltuvien keinojen määrittely on hankkeen onnistumisen kannalta merkittävää.
EN 9.2.2010 OfficialJournaloftheEuropeanUnion C32/7 Diagram 2 — Overview of ECB’s project management framework Source: European Central Bank. 
FI 9.2.2010 Euroopanunioninvirallinenlehti C32/7 Kaavio 2 – EKP:n hankehallinnoinnin rakenne Lähde: Euroopan keskuspankki.
Clear reporting lines are set in the POCP between the bodies and functions engaged in the project management process. 
Hankkeenorganisointi-javalvontamenettelyäkoskevassaasiakirjassaonmääriteltyhankkeenhallin­ nointiin osallistuvien elinten ja tehtävien väliset selkeät raportointiketjut.
The Project Steering Committee is the main ECB internal decision-making body for project prioritisation, planning, approval, and monitoring. 
Hankkeen ohjauskomitea on hankkeiden priorisoinnista, suunnittelusta, hyväksynnästä ja seurannasta vastaava EKP:n tärkein sisäinen päätöksentekoelin.
The structure created by the POCP encompasses all the necessary functions and provides clear decision-making procedures with pre-defined roles and responsibilities. 
Asiakirjassa vahvistettu rakenne kattaa kaikki tarvittavat tehtävät ja sisältää selkeät pää­ töksentekomenettelyt, joiden osalta vahvistetaan ennalta määritellyt tehtävät ja vastuualueet.
Was the governance framework established for the management of the IT projects applied as intended? 
Sovellettiinko tietotekniikkahankkeiden hallinnointia varten luotua hallintorakennetta aiotulla tavalla?
In auditing the application of the governance framework for IT projects, the Court examined whether the ECB: — planned individual projects adequately by assessing the project’s objectives and the proposed solution and by considering the resources needed, — implemented individual projects properly by ensuring that resources were made available on a timely basis and by sufficiently testing each project deliverable, — monitored project implementation by establishing systems which produce frequent reports summarising all relevant project data for informed decision making to be made, and — formally assessed the project’s deliverables and resources used at project completion. 
Tarkastaessaan tietotekniikkahankkeiden hallintorakenteen soveltamista tilintarkastustuomioistuin tutki, oliko EKP: — suunnitellut yksittäiset hankkeet asianmukaisesti arvioimalla hankkeen tavoitteet ja ehdotetun ratkaisun ja arvioimalla tarvittavat resurssit, — toteuttanut yksittäisiä hankkeita asianmukaisesti varmistamalla, että resurssit on annettu käyttöön oikea-aikaisesti, ja testaamalla riittävästi kunkin hankkeen suoritteita, — seurannut hankkeen toteuttamista laatimalla järjestelmän, jonka perusteella saadaan riittävän usein ra­ portteja, joissa esitetään yhteenveto kaikista asiaankuuluvista hankkeen tiedoista ja joiden ansiosta pää­ töksenteko tapahtuu asioista hyvin perillä ollen, — arvioinut hankkeen suoritteet ja käytetyt resurssit hankkeen päättymisen jälkeen.
Were individual projects adequately planned? 
Oliko yksittäisten hankkeiden suunnittelu asianmukaista?
The Project Submission Document (PSD) 30. 
Hankkeen esittämisasiakirja 30.
Project planning is adequate when the following are addressed: (i) the overall project objectives and scope; (ii) the proposed solution; (iii) the project milestones and deliverables; (iv) the financial and human resources; and (v) the project team. 
Hankkeen suunnittelu on asianmukaista, jos seuraavat seikat on otettu huomioon: i) hankkeen yleiset tavoitteet ja soveltamisala; ii) ehdotettu ratkaisu; iii) hankkeen välitavoitteet ja suoritteet; iv) taloudelliset ja henkilöstöresurssit ja v) hanketiimi.
EN C 32/8 Official Journal of the European Union 9.2.2010 31. 
C 32/8 Euroopan unionin virallinen lehti 9.2.2010 FI 31.
The main planning document is the Project Submission Document (PSD) (see Diagram 1). 
Tärkein suunnitteluun liittyvä asiakirja on hankkeen esittämisasiakirja (ks. kaavio 1).
This document serves as the basis for a decision as to whether the selected project solution should be imple­ mented. 
Tätä asiakirjaa käytetään päätettäessä, pitäisikö valittu hankeratkaisu toteuttaa.
In the case of all six projects examined, the content of this document was comprehensive and it addressed all main issues which should be considered at the time of project’s approval. 
Kaikkien kuuden tarkastetun hankkeen kohdalla asiakirja oli sisällöltään kattava ja siinä käsiteltiin kaikki keskeiset seikat, jotka on otettava huo­ mioon kun hanke hyväksytään.
Project authorisation and selection 32. 
Hankkeen hyväksyntä ja valinta 32.
AllprojectswereauthorisedinaccordancewiththeproceduresforeseeninthePOCP.Beforeeachof the three project phases (1), a formal decision to go ahead was taken by the Project Steering Committee. 
Hankkeen ohjauskomitea teki päätöksen hankkeen jatkamisesta ennen kutakin kolmea hankevaihetta (1).
Three projects (2) were considered as ‘must-do’ projects to comply with ESCB or other required standards. 
Kolmea hanketta (2) pidettiin EKPJ:n tai muiden voimassa olevien stan­ dardien noudattamisen kannalta välttämättöminä.
The others (3) were selected on the basis of the project prioritisation methodology. 
Toiset hankkeet (3) valittiin sen perusteella, mitkä hank­ keet oli valittu etusijalle.
All projects were consistent with either the DG-IS ‘strategic/operational outline’ or the general strategies of the Business Areas concerned. 
Kaikki hankkeet olivat yhdenmukaisia joko tietotekniikan pääosaston strategisten tai toiminnallisten suuntaviivojen tai kyseessä olevien toiminnallisten yksiköiden yleisten strategioiden kanssa.
User demands and project specifications 33. 
Käyttäjien tarpeet ja hankkeiden erityispiirteet 33.
In the case of three of the projects (4) examined, the user requirements were assessed and docu­ mented at the planning phase. 
Kolmen tarkastetun hankkeen (4) kohdalla käyttäjien vaatimukset arvioitiin ja dokumentoitiin suun­ nitteluvaiheessa.
As the other three were just an extension of an existing network (TCERTO) or an upgrade of existing infrastructure (EER and MAU), users were not involved at the planning stage. 
Kolmen muun hankkeen yhteydessä käyttäjät eivät osallistuneet suunnitteluvaiheeseen, sillä hankkeet liittyivät olemassa olevan verkon (TCERTO) laajentamiseen tai olemassa olevan infrastruktuurin (EER ja MAU) päivitykseen.
This approach was not applied in the best possible way. This resulted in delays and the test versions were not as sufficiently developed as expected. 
Tätä lähestymistapaa ei sovellettu parhaalla mahdollisella tavalla – siitä aiheutui viivästyksiä eivätkä testiversiot olleet niin kehitty­ neitä kuin oli odotettu.
Risk assessment 34. 
Riskinarviointi 34.
Risks of the non-achievement of project objectives should be identified to a sufficient level of detail, and should be structured and thoroughly assessed during the planning phase in terms of their probability and their potential impact on the achievement of the project’s objectives. 
Riskit,jotkaliittyvätsiihen,etteihankkeentavoitteitasaavuteta,olisiyksilöitäväriittävänyksityis­ kohtaisesti. Lisäksi ne olisi jäsenneltävä ja arvioitava huolellisesti suunnitteluvaiheen aikana sen kannalta, mikä on riskien mahdollisuus ja mahdollinen vaikutus hankkeen tavoitteiden saavuttamiseen.
There is a specific section on risk analysis in the templates for each of the three planning documents (5). This section was completed for all project PSDs. 
Kaikissa kolmessa suunnitteluasiakirjassa(5) on erityinen riskianalyysia käsittelevä osio. Osio oli täytetty kaikkien hankkeiden esittämisasiakirjassa.
Nevertheless, there was no common approach to the identification of the risks faced by projects, and to the assessment of their probability and impact. 
Tästä huolimatta yhtenäinen lähestymistapa hankkeiden riskien yksilöimiseksi sekä niiden todennäköisyyden ja vaikutusten arvioimiseksi puuttui.
The assessment was based on each project manager’s own experience. 
Arviointi perustui jokaisen hankepäällikön omiin kokemuksiin.
The MDP’s initial risk assessment considered only risks in relation to external contractors. 
Markkinatietojen koonnelman riskinarvioinnissa käsiteltiin ainoastaan ulkopuolisiin sopimuspuoliin liittyviä riskejä.
During project implementation, internal risks also materialised, such as resource constraints. 
Hankkeen toteuttamisen aikana havaittiin myös sisäisiä riskejä, kuten resurssien rajallisuus.
As these issues were not recognised as risks, no corrective action was foreseen at the planning stage. 
Suunnitteluvaiheessa ei ollut suunniteltu korjaavia toimia, sillä näitä seikkoja ei tunnistettu riskeiksi.
In the case of MPIDS other risks could have also been foreseen but were not mentioned in the PSD, such as the complexity of the business processes within the scope of the project. 
MPIDS-tukijärjestelmässä olisi voitu ennakoida myös muita riskejä, kuten niiden toimintaprosessien monimutkaisuus, joita oli hankkeen yhteydessä. Näitä riskejä ei kuitenkaan mainittu hankkeen esittämisasiakirjassa.
Resource management and user participation 36. 
Resurssien hallinnointi ja käyttäjien osallistuminen 36.
For three of the projects (6) examined, the resources and skills allocated to implement the project were sufficient. 
Kolmessa tarkastetussa hankkeessa (6), hankkeen toteuttamiseen oli kohdennettu riittävästi resursseja ja päteviä henkilöitä.
The other three faced a problem of specialised resources, not enough of which were made available on time. 
Kolmella muulla hankkeella oli ongelmia saada käyttöönsä riittävästi ja riittävän ajoissa erikoistuneita resursseja.
For MDP the users were not always available as a similar project had to be finalised at the same time. This led to delays in project implementation. 
Markkinatietojen koonnelmaan liittyvään hankkeeseen ei ollut aina saatavilla käyt­ täjiä, sillä samaan aikaan oli saatava päätökseen samankaltainen hanke, mikä viivästytti hankkeen toteutta­ mista.
The procurement of an external developer caused a three-month delay. 
Ulkopuolisen kehittäjän palkkaaminen aiheutti kolmen kuukauden viivästyksen.
After being contracted, the developer changed frequently, causing problems in the project implementation. 
Kun kehittäjän kanssa oli tehty sopimus, henkilö vaihtui usein, mikä hankaloitti hankkeen toteuttamista.
Due to its complexity the project was implemented in different phases (7). 
Hanketta toteutettiin monimutkaisuutensa vuoksi eri vaiheissa (7).
The knowledge transfer from phase 2 to phase 3 did not occur as planned, as most of the main former project team members including the project manager did not continue in phase 3. 
Tiedon siirto vaiheesta 2 vaiheeseen 3 ei sujunut suunnitellulla tavalla, sillä suurin osa aiemman pääasiallisen hanketiimin jäsenistä – mukaan lukien hankepäällikkö – ei jatkanut vaiheessa 3.
For most of the projects, users were represented in the PSG and/or the project team meetings and they were also informed by the monthly project status reports. 
Useimmissa hankkeissa käyttäjät olivat edustettuina hankkeen ohjausryhmän ja/tai han­ ketiimin kokouksissa ja he saivat myös kuukausiraporteista tietoa hankkeen edistymisestä.
(1) Project initiation, preparation and implementation phase. 
(1) Hankkeen käynnistys-, valmisteluja toteutusvaihe.
(2) TCERTO, Target 2 SSP and EER. 
(2) TCERTO, Target 2 SSP ja EER.
(3) MDP, MPIDS and MAU. 
(3) MDP, MPIDS ja MAU.
(4) MDP, MPIDS and Target 2 SSP. 
(4) MDP, MPIDS ja Target 2 SSP.
(5) Project Initiation Document, Project Preparation Document and Project Submission Document. 
(5) Hankkeen käynnistysasiakirja, hankkeen valmisteluasiakirja ja hankkeen esittämisasiakirja.
(6) TCERTO, MAU and EER. 
(6) TCERTO, MAU ja EER.
(7) Phase 3 was selected for audit by the Court. 
(7) Tilintarkastustuomioistuin valitsi tarkastukseen vaiheen 3.
EN 9.2.2010 OfficialJournaloftheEuropeanUnion C32/9 External contractors 38. For the MDP project an exemption was given from the ECB’s procurement rules on the basis that the procurement could not have been separated from the previous choice of the data supplier. 
FI 9.2.2010 Euroopanunioninvirallinenlehti C32/9 Ulkopuoliset sopimuspuolet 38. MarkkinatietojenkoonnelmaanliittyvällehankkeellemyönnettiinpoikkeusEKP:nhankintamenette­ lyihin liittyviin sääntöihin, koska hankintaa ei voitu tehdä erillään edellisestä tietojen tarjoajan valinnasta.
This made the development part of the maintenance release more expensive than foreseen. 
Sen vuoksi päivitysmoduulin kehittämisosuus osoittautui odotettua kalliimmaksi.
Testing and acceptance of the project deliverables during implementation 39. 
Hankkeen suoritteiden testaaminen ja hyväksyntä toteuttamisen aikana 39.
Testing of a new or changed IT deliverable forms part of the ECB’s procedures, to be carried out before each deliverable is made operational. 
EKP:nmenettelyihinkuuluuuusientaimuutettujentietotekniikkasuoritteidentestaaminen,jokateh­ dään ennen suoritteen käyttöönottoa.
All six projects were tested before release. 
Kaikki kuusi hanketta testattiin ennen niiden käyttöönottoa.
Tests were designed by the project team. However, end-users were not always involved in the development of the tests with the consequence that improvements needed were not identified in time. 
Testien suunnittelusta vastasi hanketiimi. Loppukäyttäjät eivät kuitenkaan olleet aina mukana kehittämässä testejä, joten tarpeellisia parannuksia ei aina havaittu ajoissa.
Management information systems and monitoring reports 40. 
Hallinnon tietojärjestelmät ja seurantaraportit 40.
Projectmanagersshouldhavesufficientandreliableinformationtoeffectivelymonitorprojects during implementation so that problems can be identified in good time and resolved. 
Tällöin ongelmat voidaan havaita ja ratkaista ajoissa.
The ECB uses several tools in its monitoring of its IT projects. 
EKP käyttää tietotekniikkahankkeidensa seurannassa monenlaisia välineitä.
The time spent on projects together with the financial data and information on the project’s main achievements and progress made is reflected in the monthly Project Status Report (PSR). 
Hankkeen etenemistä kä­ sittelevässä kuukausiraportissa tiedotetaan hankkeisiin kuluneesta ajasta, rahoitukseen liittyvistä seikoista sekä hankkeen tärkeimmistä edistysaskelista ja etenemisestä.
PSRs containing sufficient information were regularly produced for all six projects during their implementation. 
Kaikkien kuuden hankkeen toteuttamisen ai­ kana laadittiin säännöllisesti kuukausiraportteja, joissa annettiin riittävästi tietoa.
It was noted, though, that in the case of Target 2 SSP some reports were not prepared due to a lack of human resources. 
Target 2 SSP -hankkeen yhteydessä todettiin, että kaikkia raportteja ei ollut laadittu henkilöstöpulan vuoksi.
The time spent by staff from the Business Areas and national central banks is only estimated. 
Muiden toiminnallisten yksiköiden ja kansallisten keskuspankkien henkilöstön käyttämästä ajasta esitetään ainoastaan arvio.
Furthermore, overtime is generally not recorded consistently, or not at all. 
Myöskään ylitöitä ei yleensä rekisteröidä yhdenmukaisesti, jos lainkaan.
Therefore, monitoring is not based on complete and accurate time information. 
Tästä syystä seuranta ei perustu kattaviin ja tarkkoihin ajankäyttötietoihin.
At project closure a formal assessment of the achievement of the project objectives and resources consumed should be carried out. 
Hankkeenpäättymisenjälkeentulisisuorittaaarviohankkeentavoitteidensaavuttamisestajakäyte­ tyistä resursseista.
The POCP provides for a Project Closure Report (PCR) to be produced once all deliverables of the implementation phase have been successfully achieved and the project end-product has been accepted by the Business Area(s) concerned, by the system owner and by DG-IS/Operations. The PCR thus serves as the document with which the approval to formally close a project is given. 
Hankkeen organisointi-ja valvontamenettelyä koskevassa asiakirjassa määritellään, että hankkeen loppuraportti on tehtävä, kun toteutusvaiheen kaikki suoritteet on menestyksekkäästi saatu tehtyä ja kyseinen toiminnallinen yksikkö tai kyseiset yksiköt, järjestelmän omistaja ja tietotekniikan pääosaston käyttöpalveluista vastaava toimisto ovat hyväksyneet hankkeen lopputuotteen.
44. the (i) (ii) (iii) (iv) This document is comprehensive as it addresses all the main issues which should be considered at time of the closure of a project. 
44. Loppuraportti on kattava asiakirja, sillä siinä käsitellään kaikki tärkeimmät seikat, jotka on otettava huomioon hankkeen päättyessä.
Its main sections are: assessment of achievement of approved project scope and objectives; assessment of the use of human and financial resources; quantitative and qualitative benefits assessment; and lessons learned report. 
Sen keskeiset osat ovat: i) hankkeen hyväksyttyjen soveltamisalan ja tavoitteiden saavuttamisen arviointi; ii) henkilöstö-ja taloudellisten resurssien käytön arviointi; iii) määrällisesti ja laadullisesti mitattavien hyötyjen arviointi; iv) raportti saaduista kokemuksista.
Annex). As a general rule, the POCP provides that a project is to be closed within three months of the acceptance of the final project deliverables. 
Hankkeen organisointi-ja valvontamenettelyä koskevassa asiakir­ jassa vahvistettu yleinen sääntö on, että hanke on päätettävä kolmen kuukauden kuluessa hankkeen lopullis­ ten suoritteiden hyväksymisestä.
In the case of Target 2 SSP, operations commenced in May 2008 and the project was closed on 15 April 2009. 
Target 2 SSP -hanke aloitettiin toukokuussa 2008 ja hanke päätettiin 15. huhtikuuta 2009.
This was because DG-IS and the system owner could not agree on the contents of the Service Level Agreement (SLA). 
Tämä johtui siitä, että tietotekniikan pääosasto ja järjestelmän omistaja eivät päässeet sopimukseen palvelun tasoa koskevan sopimuksen sisällöstä.
In the PSG meeting in October 2007 it was mentioned that ‘the SLA needs to be in place before the go-live of Target 2 SSP. This needs to be started early as clear presentation of expectations/services and communication between operations and the different users are key’. 
Lokakuussa 2007 pidetyssä hankkeen ohjaus­ ryhmän kokouksessa todettiin, että palvelun tasoa koskevan sopimuksen on oltava valmis ennen Target 2 SSP:n aloittamista ja että tähän on ryhdyttävä nopeasti, sillä odotusten ja palveluiden selkeä esittäminen sekä toimien ja eri käyttäjien välinen viestintä ovat olennaisen tärkeitä osatekijöitä.