1 / 91

Pilot Implementations Workshop

Pilot Implementations Workshop. Tim McGrath, Deputy WPM WP8 Malmö, February 10 th 2010. Timetable. Who am I?. Presenting about a European project But I am Australian Discussing eProcurement But I am a document engineer Describing common standards for procurement information

oma
Download Presentation

Pilot Implementations Workshop

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Pilot Implementations Workshop Tim McGrath, Deputy WPM WP8 Malmö, February 10th 2010

  2. Timetable

  3. Who am I? • Presenting about a European project • But I am Australian • Discussing eProcurement • But I am a document engineer • Describing common standards for procurement information • But I speak only one language • Therefore… • I must be a consultant!

  4. Pilot Implementation Planning Workshop

  5. Summary Objectives of PEPPOL pilots Identifying pilots, participants and processes Roles and responsibilities for pilot participants PEPPOL business profiles Plugging in to PEPPOL Connecting the dots

  6. Summary Objectives of PEPPOL pilots Identifying pilots, participants and processes Roles and responsibilities for pilot participants PEPPOL business profiles Plugging in to PEPPOL Connecting the dots

  7. The PEPPOL project The PEPPOL project is the result of the European Competitiveness and Innovation Programme (CIP) ICT Policy Support Programme (ICTPSP) 2007 Call for Proposals • Objective: Enabling EU-wide public eProcurement • A Large Scale Pilot focused on Interoperability (Pilot A) • Key actors: Member States or national authorised representatives • The outcome should be an open, common interoperable solution with results widely disseminated and available to all Member States • The EU contribution is up to 50% of costs for achieving interoperability • Coordinated by the Norwegian Agency for Public Management and eGovernment (Difi) • 14 beneficiaries from 8 countries • Total budget 19,6 M€ • 8 work packages, <900 person months and 6,6 M€ on sub-contractors • Project start up: 1 May 2008, duration 36 months

  8. The PEPPOL project The PEPPOL project is the result of the European Competitiveness and Innovation Programme (CIP) ICT Policy Support Programme (ICTPSP) 2007 Call for Proposals • Objective: Enabling EU-wide public eProcurement • A Large Scale Pilot focused on Interoperability (Pilot A) • Key actors: Member States or national authorised representatives • The outcome should be an open, common interoperable solution with results widely disseminated and available to all Member States • The EU contribution is up to 50% of costs for achieving interoperability • From 1.11.2009 – based on enlargement proposal (subject to change) • 19 beneficiaries from 13 countries • Total budget 30,8 M€ • 8 work packages, <1.600 person months and 10 M€ on sub-contractors • Project start up: 1 May 2008, duration 42 months

  9. Consortium andOperational reference Group Consortium Operational Reference Group Regional Nodes

  10. The PEPPOL Vision Any company (incl. SMEs) in the EU can communicate electronically with any EU governmental institution for all procurement processes. v Where are you?

  11. Business requirements vary a lot • No agreed upon businesses processes • Huge difference in business models Barriers • High barriers in previous legislation • Member states implement directives differently • Different data models • Different coding systems • No common understanding • Incompatible technical solutions • Shared infrastructure components are missing Org A Org B

  12. Mandate minimal business processes • Set-up a well defined governance process Addressing the barriers • Multilateral agreements • Loosen technical requirements • Align MS implementation of directives • Define mandatory set of data-elements • Promote common standards • Accept syntax mappings will co-exist • Mandate a transport standard • Establish and fund core infrastructure Org A Org B

  13. PEPPOL will deliver... (I) • A secure, reliable and scalable European electronic transport infrastructure • Made for PEPPOL but generic in its nature – well suited also for other purposes • A market for middleware that enables easy connection between national infrastructures and the PEPPOL infrastructure • Demonstrator software supporting public procurement processes • Functioning open source software connected through the PEPPOL infrastructure • Implementing the results of the CEN WS ”Business Interoperability Interfaces in public procurement in Europe” (CEN BII) • Providing SMEs with tools to access the large European public procurement market • Basis for further development by European software industry

  14. PEPPOL will deliver... (II) • Guidance and building blocks for connecting national e-procurement solutions to the PEPPOL infrastructure • Implementing the results of the CEN WS ”Business Interoperability Interfaces in public procurement in Europe” (CEN BII) • A methodology to encompass all Member States • Availability of demonstrator software + implementation support + funding = “starter kits” that can fulfil i2010 target of 100% availability of e-procurement solutions in Europe • Long term sustainability • Governance setup and transfer of responsibility for operations of centralised components to a relevant permanent organisational unit

  15. Summary • Objectives of PEPPOL pilots • Identifying pilots, participants and processes • Post-award • Pre-award • Roles and responsibilities for pilot participants • PEPPOL business profiles • Plugging in to PEPPOL • Connecting the dots

  16. Technologies Used in PEPPOL

  17. Technologies Used in PEPPOL

  18. Transport Infrastructure Application START Interface Application Interface Access point Trusted Access Points START certificates SMP Certificate Server SML Application Access point Application Interface START Interface Trusted SMPs SMP

  19. Post-Award Transport Infrastructure (simplified) Application START Interface Application Interface Access point Application Access point START Interface Application Interface

  20. Using the Transport Infrastructure • PEPPOL provides the Service Metadata Locator. • Currently exists at NITA in Denmark. • All Service Metadata Publisher providers must: • Register with the SML using an SMP Agreement. • All beneficiaries participating in post-award processes must ensure the provision of at least one Access Point for their community. • Beneficiaries only participating in pre-award processes may also need access to an Access Point. • Each Access Point Provider will need an Agreement with PEPPOL before the production pilot stage.

  21. Transport Infrastructure Issues • Challenges: • Attracting technology providers (middleware, network providers, ERP developers) to create interfaces, SMP registries and access points • Governance issues: • Contractual obligations and service levels for service providers: • Access point Provider Agreement • Service Metadata Publisher Agreement • Transference after the pilots

  22. Technologies Used in PEPPOL

  23. Signature Validation Service Application START Interface Transformation Validation Application Interface Access point Signature Verification Service Application Access point START Interface Transformation Validation Application Interface

  24. Technologies Used in PEPPOL

  25. eCatalogue (post-award) • Supplier needs to update their customer with information about their products: • “we have a price update on the blood analysis kit #25361” • Already have a contract to supply to the customer. • May need to classify “blood analysis kit #25361” using the customer’s product classification system. Pilot Implementations Workshop

  26. eCatalogue Pilots (post award) Application START Interface Transformation Validation Application Interface Access point Following BII Profiles Application Access point START Interface Transformation Validation Application Interface Following BII Profile

  27. Technologies Used in PEPPOL

  28. eCatalogue Pilots (post award) Application START Interface Transformation Validation Application Interface Access point Following BII Profiles Application Access point START Interface Transformation Classification Template Service/Tool Validation Application Interface Containing CA’s classification template Following BII Profile

  29. PEPPOL Classification Template service • Contracting Authorities: • Link with on-line Registries(Product Property Servers) • Contract Template creation and submission to the chosen Supplier • Suppliers: • Download contract template • Mapping of existing Catalogues to the template • including integration linking to existing registries

  30. Implementing eCatalogue Post-award -1 • Each pilot Contracting Authority needs to: • Identify a willing (cross border) supplier. • Receive an eCatalogue document following the rules and processes defined by CEN/BII for the specific profile they plan to use. • NB Post-award information may differ from pre-award • e.g. the number of properties defined for an item may vary

  31. Implementing eCatalogue Post-award -2 • Each pilot supplier needs to be: • a legitimate supplier to the contracting authority. • able to create an eCatalogue document following the rules and processes defined by CEN/BII • for the specific profile they plan to use. • This may involve mapping the supplier’s products to the properties defined in the contracting authority’s template.

  32. Implementing eCatalogue Post-award -3 • Document exchanges must be via the PEPPOL Infrastructure • Supplier must have connection to a PEPPOL Access Point • Contracting Authority must have connection to a PEPPOL Access Point

  33. eOrdering • Customer has catalogue information and wants to buy products: • “we need 500 sets of blood analysis kit #25361” or perhaps that should be... • “nous voudrions acheter blood analysis kit #25361” ?? • Already have a contract with their supplier. Pilot Implementations Workshop

  34. eOrdering Pilots Application Transformation Validation Application Interface START Interface Access point Following BII Profiles Application Access point Transformation Validation Application Interface START Interface Following BII Profile

  35. Implementing eOrdering - 1 • Each pilot Contracting Authority needs to be: • Identify a willing (cross border) supplier. • able to create an eOrder document following the rules and processes defined by CEN/BII • for the specific profile they plan to use.

  36. Implementing eOrdering - 2 • Each pilot supplier needs to be: • a legitimate supplier to the contracting authority. • able to receive an eOrder document following the rules and processes defined by CEN/BII • for the specific profile they plan to use.

  37. Implementing eOrdering - 3 • Document exchanges must be via the PEPPOL Infrastructure • Supplier must have connection to a PEPPOL Access Point • Contracting Authority must have connection to a PEPPOL Access Point

  38. Implementing eOrdering - 4 • eSignaturemay also be applied • Supplier must have a certified signature • Based on prior agreement between trading partners. • Contracting Authority can verify the signature

  39. eOrdering Pilot Issues • Challenges: • Attracting suppliers wishing to participate in cross border pilots • Interfacing national procurement systems with PEPPOL Access points • Governance issues: • Maintenance of BII profiles • PEPPOL pilots may/will identify requirements for changes to BII profiles.

  40. eInvoicing • Supplier has delivered the products and wants to be paid: • “500 sets of blood analysis kit #25361 cost DKK 100,000 ” • Already have a contract with their customer. • May (or may not) have received the order electronically. • May (or may not) wish to digitally sign their invoice. • by mutual agreement Pilot Implementations Workshop

  41. eInvoicing Pilots Application Transformation Validation Application Interface START Interface Access point Following BII Profiles Application Access point Transformation Validation Application Interface START Interface Following BII Profile

  42. Implementing eInvoicing • Each pilot supplier party needs to be: • a legitimate supplier to the contracting authority. • able to create an eInvoice document following the rules and processes defined by CEN/BII • For the specific profile they plan to use. • Agree on XML syntax • Documents will be relayed via the PEPPOL Infrastructure

  43. eInvoicing Pilot Challenges Attracting suppliers wishing to participate in cross border Pilots Interfacing national procurement systems with PEPPOL Access points Mapping BII profiles to national formats Legislative differences on EU directives for taxation and evidence

  44. eInvoicing Pilot Governance • Maintenance of BII profiles • PEPPOL pilots will identify requirements for changes to BII profiles • a suitable governance mechanism needs to accommodate these changes. • Revised archiving and auditing processes may be required

  45. Summary • Objectives of PEPPOL pilots • Identifying pilots, participants and processes • Post-award • Pre-award • Roles and responsibilities for pilot participants • PEPPOL business profiles • Plugging in to PEPPOL • Connecting the dots

  46. Technologies Used in PEPPOL

  47. Pre-Award Transport Infrastructure Application Pre- and Post-award START Interface Application Interface Other Interface Access point Pre-award Application Access point START Interface Application Interface Other Interface

  48. Technologies Used in PEPPOL

  49. VCD Pilots Application START Interface Transformation Validation Application Interface Other Interface Access point Following BII2 profiles Application Access point START Interface Transformation Pre-VCD Tool Validation Application Interface Other Interface Ontology defined for both/all parties Following BII2 profiles

More Related