PUR1308/14
Request for Proposals
PUR1702/08
-----------------------------------------------------------Provision of professional services to support the
development of Project Pegasus
------------------------------------------------------------
PUR1702/08
1.0
INTRODUCTION
The European Bank for Reconstruction and Development (the "Bank") is an
international financial institution. The Bank was established by treaty in 1990, with its
headquarters in London, to foster the transition towards open market oriented
economies and to promote private and entrepreneurial initiatives in Central and Eastern
Europe, the Baltic States and the Commonwealth of Independent States that are
committed to and applying the principles of multiparty democracy, pluralism and
market economics.
The Bank has 67 members (65 countries, the European Union and the European
Investment Bank). Further information about the Bank's roles and activities can be
found on the Bank's website: www.ebrd.com.
1.1
Definitions:





The terms ‘EBRD’ and ‘The Bank’ shall mean the European Bank for
Reconstruction and Development.
The term ‘Supplier(s)’ shall mean a party that submits a proposal in
accordance with this RFP.
The term “Tender” shall mean the process by which the Bank evaluates
and selects a Supplier to provide the Services described herein.
The term ‘RFP’ shall mean Request for Proposal.
The term ‘Proposal’ shall mean a combination of the documents defined
in section 4.4 of this RFP. Specifically the Technical Proposal and the
completed Quotation File.
2.0
PROJECT BACKGROUND
2.1
Background
Project Pegasus will replace and enhance a set of existing Bank applications referred to
as ‘BOLDnet’ (or Board online documents) which have been built on a Lotus Domino
platform. In essence, BOLDnet is a set of tools for managing the Bank’s executive body
(Board and Executive Management Committee) meeting calendars and linking these
meeting agendas with a dedicated document archive. It is used by 2000+ staff within the
Bank and approximately 250 external users . The user list includes:








The Bank’s Board of Directors, Assistants & Advisers
Office of the Secretary General & the Documentation Office
Shareholder representatives in national capitals (i.e. external, non-EBRD users)
The Bank’s Executive Management team (including members of the Executive
Committee and all other senior management commitees)
Assistants and delegates to the Bank’s Executive Management team
Events Management / Administration Services
The Bank’s Nuclear Safety department
Other Bank staff (on request)
1
PUR1702/08
The BOLDnet suite of applications supports multiple layers in the Bank’s Corporate
Governance structure and a range of different types of meeting, as illustrated below:
KEY: Green / red colour scheme denotes whether or not the meetings are supported by
the existing EBRD ‘BOLDnet’ software platform
Aside from supporting these committees, the current platform also stores and shares
information regarding the Bank’s shareholders and our Nuclear Safety Funds. These
capabilities will also need to be migrated to the new technology platform.
Access will be restricted to specific users within the Bank and a limited number of
external authorised representatives of the Bank’s shareholders. Further access
restrictions will apply to documents and information via a security matrix that takes into
account both the user’s profile and the information classification level of the material.
The proposed new system is to provide secure access to confidential information
including Board-level project documents, country strategies, meeting agendas and
minutes. Delivery of a new system that has been designed with mobility and electronic
working in mind is intended to a result in a significant reduction in the amount of
printing and hard copy documents currently necessary to run Board and Executive
Management events.
Rollout into Production should take place in an iterative, agile manner during the first
half of 2018 with an initial MVP (Minimum Viable Product) live by early January 2018.
The successful supplier will have a proven and demonstrable track record of delivery in
Agile Development using the technologies described in Appendix B.
2
PUR1702/08
3.0
EBRD CONTACT DETAILS
Your sole contact for the purposes of the RFP is:
Darren Fox – Corporate Procurement Unit
EBRD
One Exchange Square
London, EC2A 2JN
Telephone: 020 7338 7661
Email: [email protected]
4.0
DESCRIPTION OF THIS RFP
4.1
Overview
Suppliers wishing to participate in this Tender will be required to make a submission
(the ‘Submission’) comprising the following documents in accordance with the
timetable outlined in section 4.2:



4.2
a completed minimum requirements checklist (the “Checklist”) as defined in
section 4.4;
a technical proposal (the ‘Technical Proposal’) as defined in sections 4.4 and
4.5; and
a completed quotation file (the ‘Quotation File’) as defined in section 4.6.
Timetable
Task
Issue of RFP to suppliers
Deadline for suppliers to issue clarification requests
Deadline for submission of Proposals
Supplier presentations
Opening of Financial Proposals
Notification of award to preferred supplier
Contract negotiation and signing
Dates
11th April 2017
21st April
12th May 2017 by 2pm
22nd –25th May 2017
w/c 7th June 2017
w/c 26th June 2017
by 14th July 2017
The EBRD reserves the right to amend or change these dates at any time.
4.3
Clarifications
The process for receipt and resolution of queries shall be as follows:





Suppliers should send queries by e-mail to the following address:
[email protected];
there will be one round of queries;
the deadline for queries is shown in the timetable set out in section 4.2 of this
RFP;
the EBRD will circulate the responses to all queries to all participating Suppliers
in accordance with the timetable set out in section 4.2 of this RFP; and
the clarification document will make no reference to which Supplier made any
particular query.
3
PUR1702/08
4.4
Technical Proposal
The Technical Proposal shall consist of: a completed version of the Checklist attached
to this RFP as Annex A – Minimum Requirements Checklist and a narrative response
prepared with reference to Annex B – Scope of Services which at a minimum should
provide the following:
(i)
An implementation plan showing high level tasks, milestones and resources
you will provide and require from EBRD. Please address:
o
o
o
o
the resource expectations from the EBRD team indicating the type of
resource (technical or business);
any assumptions that have been made in creating the proposal;
any specific facilities or environmental requirements given that the
assignment will take place at the Bank’s headquarters in London;
how a minimum viable product (see Appendix A for further details)
will be delivered into production in early January 2018, assuming
supplier team are on site within one week of completion of contract
negotiation in accordance with the timetable detailed in section 4.2.
Please note that the cost of delivering minimum viable product and the
cost of delivering full implementation should be included in the
Quotation file only (see Appendix D), It should not be included in the
technical proposal.
(ii)
A description and detail of the experience of the proposed project team
members, including CVs. This should include all proposed team members to
include a Project Manager and all Technical resources. This should include
an explanation of where 3rd party resources are included in the Submission
(iii)
Between one and three case studies of recent implementations which
demonstrate your experience of similar projects. Where possible these
should include the following technology stack: Tomcat / JBoss, JMS,
Hibernate, XML, Javascript/HTML/CSS and also connectivity to Microsoft
Exchange; connectivity to a document management store using the CMI-S
API; connectivity to an enterprise Portal Framework (in particular Backbase
CXP); use of a DevOps Infrastructure.
(iv)
The Project will be implemented using a number of technologies
highlighted in Appendix B. Please explain how you will deliver into this
architecture, highlight any risks that you perceive and explain how you have
dealt with such risks in past implementations. What challenges do you
anticipate delivering into this architecture? Please also highlight any lessons
learned from previous projects.
(v)
Please explain how you will deliver the business requirements detailed in
Appendix A, highlight any risks that you perceive and how you have dealt
with such risks in past implementations. Are there any requirements listed in
Appendix A which are particularly problematic or likely to be difficult to
implement? Please also highlight any lessons learned from previous
projects.
4
PUR1702/08
(vi)
Please explain your approach in clarifying requirements, engaging
stakeholders, design and user experience, documentation and other
deliverables.
(vii)
Please provide an example wireframe mock-up of the key MVP
deliverables.
(viii)
Please provide a detailed overview of the architecture including component
overview (based on the templates provided in Appendix B) that will be used
to build the solution.
(ix)
Please provide details of two customers for reference. References should be
for customers with requirements as similar as possible to those of EBRD.
(x)
Please provide company financial information for the past 3 years of filings
with Companies House.
Additional Information (optional)
(xi)
EBRD will consider proposals for support and maintenance of the software
after the final production delivery. Note that this will not be included in the
evaluation criteria for the proposal.
4.4.1 Presentation
In addition to the written narrative response, Suppliers will be invited to make a
presentation at the Bank. The presentation should last no more than 90 minutes and will
cover the topics identified below. The presentations period is scheduled 22nd – 25th May
2017.
Suppliers will be notified by e-mail the date and time they must attend the presentation.
Best efforts will be made to give Suppliers a minimum of 48 hours’ notice of their
presentation slot. The allocated meeting slot will not be negotiable.
i) Overview of the implementation


Explain the implementation plan
Project resourcing and approach
ii) Case Studies and relevant technical experience

Discussion of case studies and how they are relevant to Pegasus
iii) Understanding of the technical requirements
 Expand on technical requirements
 Discuss likely issues and risks
5
PUR1702/08
iv) Understanding of the business requirements


Expand on business requirements with reference to wireframe mock-ups
Discuss likely issues and risks
v) Questions
4.5
Technical Proposal Submission
Responses shall be submitted to the EBRD contact on a CD or a USB drive and in an
original hard copy by courier in a sealed envelope clearly identified as “PUR1702/08 –
Provision of professional services to support the development of Project Pegasus –
Technical Proposal” in accordance with the timetable set out in section 4.2 of this RFP.
4.6
Quotation File Submission
All Suppliers are required to complete the applicable quotation file (the ‘Quotation
file’) attached as Appendix D of this RFP. Prices are to be quoted in GBP net of VAT.
The Quotation File must be submitted:



on a CD or a USB drive by courier in a sealed envelope clearly identified as
“PUR1702/08 – Provision of professional services to support the development
of Project Pegasus – Quotation file”;
in an envelope clearly bearing the Suppliers’ name; and
in accordance with the timetable set out in section 4.2 of this RFP.
The Quotation file should be submitted in a separate sealed envelope to the Technical
Proposal Submission
Quotes submitted shall be valid for ninety (90) days following date of receipt.
5.0
EVALUATION METHODOLOGY
Table 1.
Elements of the Evaluation
Implementation plan
Project resourcing and approach
Case studies and relevant
technical experience
Understanding of the business
requirements
Understanding of the technical
requirements
Technical subtotal
Maximum Financial Score
OVERALL MAXIMUM
SCORE
Maximum
Score
available
15
15
15
20
15
80
20
100
6
PUR1702/08
5.1
Technical Evaluation
Suppliers’ Technical Proposals will be evaluated and scored by a nominated Tender
Evaluation Panel (TEP) of Bank staff selected from operational departments who are
directly involved with the services to be provided.
A minimum technical threshold applies to this procurement process. A Supplier will be
deemed to have passed this threshold on meeting all of the following conditions:


a majority of the TEP allocate it 75% (60 points) or higher of the maximum
points available for the technical evaluation;
the mean of the combined TEP scores is 75% (60 points) or higher of the
maximum points available for the technical evaluation.
5.2
Financial Evaluation
Following the review of the Technical Proposals, the Quotation files of those Suppliers
who have passed the technical qualification threshold will be opened. The Bank will
calculate a total bid price for each Supplier based on its proposal. The Supplier
proposing the lowest total bid price will be given the maximum financial score available
(20). Other Suppliers’ (higher) prices will be divided into the lowest price and the result
multiplied by the maximum score given.
FSa = LP/EPa x Maximum Financial Score
FSa
LP
EPa
= financial score for proposal a
= the lowest evaluated financial proposal
= the financial proposal of a.
5.3
Preferred Supplier
The Supplier achieving the highest combined score following the technical and financial
evaluations shall be nominated as the preferred Supplier (the ‘Preferred Supplier’).
5.4
Checking of References
The Bank may contact the two references provided by the Preferred Supplier. The Bank
reserves the right to speak to any company which has dealt with the Preferred Supplier,
whether provided as a reference or not, without prior notification to the Supplier.
In the event that the Preferred Supplier’s references prove unsatisfactory, the Bank will
consider the next highest scoring Supplier to be the Preferred Supplier and will repeat
the procedure described above.
5.5
Negotiations
The Bank will move to negotiate a contract with the Preferred Supplier. In the event that
a satisfactory conclusion to the contract negotiations cannot be agreed the Bank may
consider the next highest scoring Supplier to be the Preferred Supplier and will
commence the procedure described above.
5.5
Right to Reject
The Bank reserves the right to accept or reject any RFP response, or part thereof, and to
annul the RFP process and reject all RFP responses at any time prior to award of
contract without incurring any liability to the affected parties.
7
PUR1702/08
6.0
CONTRACT
6.1
Status of the EBRD
The EBRD is an international organisation established by international treaty. As such,
the EBRD possesses a special status under public international law which has been
confirmed under English law through statute (Statutory Instrument 1991, No. 757, The
European Bank for Reconstruction and Development (Immunities and Privileges) Order
1991), available at: http://www.legislation.gov.uk/uksi/1991/757/contents/made.
Please also refer to the aforementioned establishment treaty of the Bank ("articles of
incorporation") which lays out the immunities as found in Chapter VIII. These can be
found at: http://www.ebrd.com/pages/research/publications/institutional/basicdocs.shtml
The special status of the EBRD requires it to seek specific provisions relating to such
status in all contracts with external suppliers and service providers. EBRD is unable to
agree to terms that expressly contradict its special status and internal policies as an
international organisation.
6.2
Contract Negotiation
The contract awarded shall be performed in accordance with the contract sample
contained in Appendix D of this RFP.
7.0
GENERAL TERMS AND CONDITIONS OF THIS RFP
7.1
Amendment
EBRD reserves the right to negotiate any or all terms and conditions, and to cancel,
amend or resubmit this RFP in part or entirely at any time. None of the terms and
conditions of this RFP can be revoked or amended in any way by Suppliers without the
prior written agreement of EBRD.
7.2
Supplier Costs
EBRD is not responsible for any Supplier costs associated with this RFP, Supplier
responses or any contract discussions or negotiations. Nor is EBRD responsible for any
indirectly related costs. No statement by EBRD should be viewed as a request by
EBRD or justification for Suppliers to increase or change inventory, staff, facilities,
business relationships with its suppliers, or internal business processes. All actions by
Suppliers in response to this RFP or subsequent discussions or negotiations should be
taken with the clear understanding that neither this RFP nor subsequent actions or
omissions by EBRD obligate or commit EBRD to pay or reimburse Suppliers for any
costs or expenses they incur. This RFP is not an offer to enter into a contract.
7.3
Professional Competence
Suppliers shall absolutely rely on their own professional competence in evaluating and
verifying the information contained in this RFP. Suppliers must take every opportunity
to inspect and verify the information contained or referred to in this document or
subsequent to it, subject to the confidentiality restrictions as detailed in section 7.6 of
this RFP.
8
PUR1702/08
7.4
Intellectual Property
The information contained in this RFP will remain EBRD’s intellectual property.
Suppliers are granted a limited, revocable license to use the same for the purpose of
responding to the RFP. By submitting a response to the RFP Suppliers grant EBRD a
royalty free, irrevocable license to use the intellectual property in the proposal for its
internal business purposes in relation to the procurement of the services required.
7.5
Sole Response
Submission of a response as part of this process shall be deemed to be the Suppliers’
only offer(s).
7.6
Confidentiality
Suppliers shall treat the RFP and EBRD's process of evaluating Suppliers as strictly
private and confidential. The contents of this RFP, including specification, designs,
drawings or other related documents shall be considered confidential and shall not be
disclosed by the Supplier, the Supplier’s servants or agents to any persons, firm or
corporation without the prior written consent of EBRD. Any such specifications,
designs, drawings or other documents shall remain the property of EBRD and shall be
returnable to EBRD within five (5) days of the Supplier receiving either, notification
that it has been unsuccessful, or on written request from EBRD.
7.7
EBRD Logo Protection
Please be advised that EBRD logo is a registered service mark and as such should not
be reproduced without the express written permission of the Bank.
7.8
General
Incomplete or inadequate responses, lack of response to an item or items, or
misrepresentation in responding to this documentation may result in rejection of a
Supplier’s Proposal.
After receipt of the RFP and until the award of any contract, neither information relating
to the examination, clarification, evaluation and comparison of the submissions nor
recommendations concerning the award of a contract shall be disclosed to the Supplier,
or to any other outside parties, until the RFP process has been concluded and a contract
awarded.
Any effort by a Supplier to influence EBRD in the process of examination, evaluation
and comparison of the RFP, or in decisions regarding the award of a contract, shall
result in the rejection of the Supplier’s Proposal.
Ownership of documentation or other information submitted in the RFP will become the
property of EBRD unless otherwise requested at the time of submission. Any materials
submitted in response to the RFP, which are considered to be confidential, should be
clearly marked as such by the Supplier.
9
PUR1702/08
ANNEX A – MINIMUM REQUIREMENTS CHECKLIST
Please note only Suppliers who can answer “yes” to all of the following questions are eligible to
participate in this tender,
Service Minimum Requirements
Yes/ No
Demonstrable Experience of using full DevOps Tool Chain (at least 2 Yes/No
projects)
Demonstrable Experience of following technology stack: Tomcat /
JBoss, JMS, Hibernate, XML, Javascript/HTML/CSS (at least 2
projects)
Yes/No
Demonstrable Experience of Agile methodology project implementation Yes/No
(at least 2 projects)
Ability to resource a project based on implementation plan included in Yes/No
response to deliver a minimum viable product into Production by early
January 2018 assuming completion of contract negotiation in
accordance with the timetable detailed in section 4.2
Availability of Legal team to expedite contract negotiation in Yes/No
accordance with the timetable detailed in section 4.2
Availability of Supplier team to be onsite within one week of contract Yes/No
signature
The Supplier organisation must have had a minimum of 5 years’ Yes/No
company trading experience.
The Supplier must have existing clients who have completed a Yes/No
significant development project where the supplier has been the prime
supplier of detailed application design, development and testing
services.
PUR1702/08
Yes/ No
Information Security Minimum Requirements
Do you have an information security policy and/or data privacy policy Yes/No
and/or another policy covering the services that you will be delivering to
EBRD?
Do you have a security policy that addresses the secure handling of Yes/No
sensitive and/or confidential/restricted data, whether that data is
commercial or personal data?
Do you have procedures to safeguard EBRD data that may be Yes/No
transferred from EBRD to your organisation, including data transferred
overseas?
Do you have sufficient controls, physical and logical, to prevent access Yes/No
to EBRD data, including backups and test systems?
Do you provide staff with training to ensure that they are fully aware of Yes/No
how to handle sensitive data securely?
Do your staff/supplier contracts or terms and conditions specifically Yes/No
mention information security and data privacy responsibilities with
respect to sensitive data?
Do you have a policy for the procedures and processes to deal with Yes/No
allocation and revocation of user privileges relating to access to EBRD
data?
Yes/ No
Minimum Contractual Terms
The special status of EBRD requires it to seek specific provisions Yes/No
relating to such status in all contracts with external suppliers and service
providers. EBRD is unable to agree to terms that expressly contradict its
special status and internal policies as an international organisation.
Suppliers are required to confirm that they understand and accept this.
The Supplier agrees that the basis of any contract will be the template Yes/No
attached to this RFP as Annex D.
The Supplier confirms that they accept the following mandatory clauses in the
Bank’s standard terms & conditions for the provision of services.

Section 14 : Prohibited Practices and Retaliation
(Clause 14.1, 14.2 and 14.3)

Section 33 : Governing Law and Dispute Resolution
(Clause 33.1, 33.2, 33.3 and 33.4)
Yes/No
PUR1702/08
ANNEX B – SCOPE OF SERVICES
1.
BACKGROUND
The Bank is seeking to establish costs for project implementation broken down by the following functional areas
(see Appendix A for further detail):









core functionality;
documents;
calendars, events and agendas ;
management of executive bodies;
management of shareholder information;
management of Nuclear Safety Fund information;
user permissions and Information Security;
paper reduction and mobile working; and
data and document migration.
The solution should be developed in an Agile methodology using Java. The application will be deployed within
the Bank’s Backbase CXP Portal within the Extranet. Both internal and external users will be authenticated via
the Forgerock AM component which will be integrated with Backbase CXP. It should have connectivity to Office
services via REST API for event room booking and to document management via the CMIS API. Workflow tasks
should be handled via the Bank’s Unified Task Manager solution. The high level technical architecture and
constraints are further detailed in Annex B.
2.
OBJECTIVES
The scope of the assignment (the “Assignment”) is to provide technical design and development implementation
services to implement the functionality in an agile manner based on user stories and the requirements described in
Appendix A.
This technical design and build will include the following aspects:
1.
2.
3.
4.
5.
Decommission the Lotus Domino platform infrastructure.
Migrate to system solutions that are adequately supported and maintained.
Migrate to a solution that has streamlined information and process flows, requiring less administrative
overhead with flexible support for changes to committee structures and approval paths.
Delivery of a unified solution such that the following key application capabilities are either maintained,
or where possible, enhanced:
o meeting scheduling;
o agenda construction;
o electronic document distribution and review; and
o information and documentation search, retrieval and access by appropriate internal and external
users.
Significantly reduce the amount of paper used in the running of Board and Executive Management
events through successful delivery of appropriate electronic, mobile-compatible application capabilities.
PUR1702/08
3.
ENGAGEMENT APPROACH
The project will have a discovery phase to discuss and validate requirements and convert the requirement
specifications detailed in Appendix A into an implementable backlog using the Agile methodology. The discovery
phase should also include production of a detailed technical design as well as selection and validation of secure
viewer technology for highly restricted documents. Production Rollout should take place during the first half of
2018 with an initial MVP (Minimum Viable Product) going live in early January 2018. This is a key target date
for the Bank. Further deliveries should take place in an iterative agile manner with the final delivery by the end of
June 2018.
The supplier team will work with EBRD to what will constitute the initial MVP. For the purposes of this RFP, the
MVP is assumed to include at least:



All core document and event capabilities
Delivery to one or more Executive Management Committees (i.e. a subset of committees and ones with
only Bank staff users)
The migration of data, relevant to the selected committee(s)
Those items that could be launched after the MVP are assumed to include:






Full mobile and tablet compatibility
Lower priority administration capabilities
Support for Highly Restricted documents and integration with the secure viewer capability
Provision of access to external users
Roll-out to the Board and to the remaining Executive Management Committees
A full data migration and de-commissioning of the current platform
A more detailed view of what is assumed to constitute the MVP is included in Appendix A.
The supplier team should work on the EBRD site, embedded within EBRD team which will include a Business
Analyst, a Project Manager, EBRD business users and a tester. We would expect the supplier to provide the agile
development team including user experience expert, Agile PM (scrum master) and other developers reporting into
the EBRD Project Manager. We expect EBRD to supply UX guidelines.
The Supplier will be fully involved in planning sprints, and phased deliveries into Production. It is envisaged that
some support of go-live will be required including maintenance of Production during a 6 month period
commencing from the first production release in early January 2018 and a further period of between 3 and 6
months following the final delivery. In the long term it is envisaged that there will be handover into BAU Support
after the end of this period, but EBRD will consider proposals for provision of ongoing support and maintenance
of the software after the final production delivery. Note that this will not be included in the evaluation criteria for
the proposal.
Assumptions


The project team to be based at the EBRD HQ
User Testing carried out by EBRD
PUR1702/08
APPENDIX A - REQUIREMENTS
Those items flagged as MVP are, for the purposes of this RFP, assumed to constitute the scope of the initial
production release in early January 2018. The remaining requirements are assumed to be rolled-out
through iterative production releases to be concluded by the end of June 2018.
1.0 CORE FUNCTIONALITY
ERM 001
Description
Assumption(s)
ERM 002
Description
Rationale /
Commentary
Assumption(s)
ERM 003
Description
Rationale /
Commentary
Events
MVP
The new system must support the concept of events. For every uniquely identified event, the
system must, at a minimum, be able to store the following attributes:
- Title
- Starting date and time
- Finishing date and time
1. As well as the new system, this basic event data will also be held in both the new
Room Booking system and individual users’ personal diary/calendaring system. Where
possible, this common information will need to be synchronised to ensure there are no
contradictions.
2. It is assumed that events will be created within the new system and a subset of the
event data sent to the Room Booking system and the users’ individual calendars.
Event Types
MVP
The new system must support the concept of event types. Every uniquely identifiable event
must correspond to a single event type. For every uniquely identified event type, the system
must, at a minimum, be able to store the following attributes:
- Name
The concept of event type will allow for a number of useful system functions from having a set
of defaults (attendees, location, agenda items) to granting type-specific calendar views (e.g.
display only Board meetings)
1. Event types will be configured by system administrators and maintained on an ongoing
basis to cater for potential business change. When creating an event, the user would
make a selection from a pre-defined list of event types.
2. It is expected that event types will be specific to the new system – the new Room
Booking system and individual users’ personal diary/calendars are not expected to
need to differentiate between event types.
Event Sessions
The new system could support the concept of event sessions. A session would belong to a
uniquely identifiable event. An event could have multiple sessions, thus allowing the organiser
to sub-divide an individual event into multiple smaller uniquely identifiable sessions. Each
session could have the following attributes:
- Name
- Starting date and time
- Finishing date and time
- Location
This requirement will replicate existing functionality used to support multiple day or location
events. Low priority given a potential workaround of setting up multiple, shorter events
PUR1702/08
ERM 004
Description
Rationale /
Commentary
Assumption(s)
ERM 005
Description
Rationale /
Commentary
Assumptions
ERM 006
Description
Rationale /
Commentary
Assumption(s)
Event Items
MVP
The new system must support the concept of event items. An event item would belong to a
uniquely identifiable event. The system must allow an individual event to have multiple event
items. Each item must, at a minimum, have the following attributes:
- Name
- Order
- Information Security Classification
A collection of event items can be thought of as making up an event/ meeting agenda, hence
the need for an ordered list. The fact that Information Security Classification is at an item level
is important since it will allow for item specific visibility/access permissions for sensitive
topics.
1. It is expected that event items will be specific to the new system – the new Room
Booking system and individual users’ personal diary/calendars are not expected to
require or hold this information.
Event Item Types
MVP
The new system should support the concept of event item types. Every uniquely identifiable
event item should correspond to a single event item type. For every uniquely identified event
item type, the system should be able to store the following attributes:
- Name
Event item types have limited impact on the current platform. However in future their use
represents one method of differentiating between different types of action required on the item
– e.g. from requiring approval, to those submitted for no objection approval, to those items that
are purely for information purposes. This distinction is likely to make event agendas more
usable and allow for the potential ‘search and retrieval’ of particular item types.
1. Item types will be configured by system administrators and maintained on an ongoing
basis to cater for potential business change. When creating an event agenda, the user
would then create new items from a pre-defined list of item types.
Document Profiles
MVP
The new system must support the concept of document profiles. A document profile must exist
in its own right on the system but must be able to be optionally linked to an event via
association with a uniquely identifiable event item. For every uniquely identified document
profile, the system must be able to store any number of physical file attachments (0, 1 or many)
plus the following minimum data attributes:
- Title
- Reference Number
- Type
- Description / abstract
- Author
- Date
- Information Security Classification
These data attributes (or ‘metadata’) will allow the systems to store and categorise the physical
attachments in a more sophisticated manner that simply moving them into a new location. For
example users should be able to use the descriptions, dates and types as effective means for
searching and retrieval. The unique reference number should allow users to retrieve a known,
specific file
1. Physical files will be accessed by users via the new system but will be stored in the
Bank’s separate Document Management Store.
2. Document profile metadata will be managed inside the new system.
3. The required document profile metadata may vary by document type
4. The Information Security Classification will apply at document profile level, rather
than individual document file attachment level
PUR1702/08
ERM 007
Description
Rationale /
Commentary
Assumption(s)
ERM 008
Description
Rationale /
Commentary
Assumption(s)
Document Profile Status
MVP
The new system should extend the concept of Document Profile to include the provision for
document status. Document status will be used to differentiate between various approval states
(e.g. submitted for approval, approved or submitted for information etc.)
This concept should allow users to differentiate between documents that are still in draft form
from those that have been approved or between those which are internal working documents
and those that have been published externally. The concept may also allow for further
efficiency gains through the development of part-automated workflows as documents progress
through the Bank’s Corporate Governance approval cycle.
1. Document profile statuses will be managed inside the new system.
Document Profile Group
MVP
The new system should support the concept of document profile group which should act as a
mechanism for linking multiple document profiles together that the user considers to be related.
The new system should allow a user (subject to access permissions and visibility rules) to be
able to view an ordered list of all related document profiles.
The concept allows for the well-known concept of document versions but is extended to allow
for a broader definition of related document profiles which could include document revisions,
corrections and addendums.
1. The concept of linked document profiles will not be limited to a single document type
or event i.e. it is considered possible that a single document profile group could contain
documents of different types and submissions to multiple committees in the Bank’s
Governance Structure.
2.0 DOCUMENT RELATED REQUIREMENTS
2.1 DOCUMENT STORAGE
DOC 001
Description
Rationale /
Commentary
Assumption(s)
Create Document Profile (Store and Publish Document)
MVP
The new system must allow a user (subject to access permissions) to create and store document
profile records. For every uniquely identified document profile, the system must allow the user
to upload any number of document file attachments (0, 1 or many) and be able to store the
following minimum attributes:
- Title
- Reference Number
- Description / abstract
- Type
- Author
- Date
- Subject country
- Information Security Classification
The system(s) must store, publish and index the document profile according to this metadata
such that it can subsequently be retrieved by other system users.
These data attributes (or ‘metadata’) will allow the systems to store and categorise the physical
attachments in a more sophisticated manner that simply moving them into a new location. For
example users should be able to use the descriptions, dates and types as effective means for
searching and retrieval. The unique reference number should allow users to retrieve a known,
specific file.
1. Physical files will be accessed by users via the new system but will be stored in the
Bank’s separate Document Management Store.
2. Document profile metadata will be managed inside the new system.
3. This function will be restricted by role
4. The document file attachments will be uploaded from an existing EBRD file store
PUR1702/08
5. The required document profile metadata may vary by document type.
6. Document profiles will be created with the intention to have at least 1 document file
attachment. However document profiles can be created before the physical document
file is ready to be uploaded (e.g. placeholder profile)
7. The Information Security Classification will apply at document profile level, rather
than individual document file attachment level
8. Full visibility and access to the physical documents will be subject to user access
permissions. To avoid instances of reports of missing or lost documents, it is expected
that, in some circumstances, a stub of a document profile (including reference number)
should be visible to a user, even if they are not entitled to access the full profile and/or
file(s).
DOC 002
Description
Rationale /
Commentary
Assumption(s)
DOC 003
Description
Rationale /
Commentary
Assumption(s)
Submit Document Profile For Approval
The new system should allow a user to create document profile records and submit them for
approval and publication. For every uniquely identified document profile, the system should
allow the user to upload one or more document file attachments and be able to store the
following minimum attributes:
- Title
- Reference Number
- Description / abstract
- Type
- Author
- Date
- Subject country
- Information Security Classification
The new system should submit these ‘draft’ records to a user, or set of users with sufficient
access privileges, to review, amend and approve the record. Once the approved, the system
should store, publish and index the document profile according to this metadata such that it can
subsequently be retrieved by other system users.
This requirement would allow potentially any user in the Bank to submit document profiles and
files. This would lessen the administrative burden of entering document profile metadata and
put more emphasis on the submitting team/user to provide information in a well-defined
format. By incorporating an approval step, we allow control of the documents and their
metadata to be retained by a smaller, most qualified set of users – the Bank’s Documentation
Office and meeting secretariats.
1. Physical files will be accessed by users via the new system but will be stored in the
Bank’s separate Document Management Store.
2. Document profile metadata will be managed inside the new system.
3. The submit function would be available to all Bank users, the approve function would
be restricted by role
4. The document file attachments will be uploaded from an existing EBRD file store
5. The required document profile metadata may vary by document type
Edit / Update Document Profile
MVP
The new system must allow a user (subject to access permissions) to update previously created
and stored document profile records. For every uniquely identified document profile, the
system must allow the user to update all previously stored attributes. The new system must
store, publish and index the updated document profile according to this metadata such that it
can subsequently be retrieved by other system users.
This function will allow the user to correct and amend previously entered document profile
details.
1. Updating document profile metadata will create a new version of the document profile
record (i.e. .the both the new and previous record will be visible to the users of the
PUR1702/08
system, unless this previous version is removed/hidden – see DOC 007)
2. Changing the attached document file records will constitute an edit of the document
profile record. All changes with respect to document file records will constitute a new
version (i.e. a new document profile record in the same document profile group)
3. This function will be restricted by role
2.2 DOCUMENT PROFILE GROUPS
DOC 004
Description
Rationale /
Commentary
Assumption(s)
DOC 005
Description
Rationale /
Commentary
Assumption(s)
DOC 006
Description
Rationale /
Commentary
Assumption(s)
Linking Related Document Profiles (Profile Groups)
MVP
The new system must allow a user (subject to access permissions) to link together two or more
document profile records together and in doing so create a relationship, or ‘document profile
group’. The new system must store, publish and index the updated document profile records
such that when viewing a document profile record other system users can (subject to access
permissions) also view all related document profiles. The new system must order all related
document profile records by date such that the system user can determine the most recent
record.
The current applications currently have the concept of related document profiles - achieved by
displaying all document profiles in the same series according to their reference number. This
requirement represents an extension to this concept since it is not restricted to reference
number but can be any profile that the user considers to be related. It is expected to include
addendum, revisions and corrections but also allow for linking documents being discussed at
different committees on the same topic.
1. The concept of linked document profiles will not be limited to a single document type
or event i.e. it is considered possible that a single document profile group could contain
documents of different types and submissions to multiple committees in the Bank’s
Governance Structure.
2. Visibility and access to each document profile will be subject to user access
permissions.
3. The new system will help to ensure users can differentiate between successive versions
of the same document and associated or ‘linked’ documents.
Clone Existing Document Profile
The new system should allow a user (subject to access permissions) to select an existing
document profile and use the information to pre-populate a new document profile record. The
new system should prepopulate the record metadata, link the two records in a single document
profile group but allow the user to review and amend. At a minimum, the new document
profile record should require a new reference number and document file attachment.
This function will save the user time in adding new document profiles to the system. One key
use of the function will be in adding new versions and revisions to existing documents as much
of the metadata attributes will be unchanged.
The new system should not enforce that cloned profile records are related/linked in a document
profile group. This will be the case in many circumstances, but not all.
Return Potentially Related Document Profiles
As a user is attempting to create a new document profile record, the new system should return a
list of existing document profiles that, based on the stored metadata, may be related.
The system should allow the user the option of selecting one of the returned results to link the
new and existing record under a document profile group.
This function will help the user to link related documents and not rely on the user knowing
whether or not a related document already exists on the platform. This is considered
particularly important if document profiles created by different users are to be linked together
(e.g. if records from different committees are to be linked).
1. The search on existing document profiles will be based on a few attributes including
PUR1702/08
title and reference number
2. Full visibility and access to the document profiles and attachments will be subject to
user access permissions. To avoid instances of reports of missing or lost documents, it
is expected that, in some circumstances, a stub of a document profile (including
reference number) should be visible to a user, even if they are not entitled to access the
full profile and/or file(s).
2.3 DOCUMENT ADMINISTRATION
DOC 007
Description
Rationale /
Commentary
Assumption(s)
DOC 009
Description
Rationale /
Commentary
Assumption(s)
DOC 010
Description
Rationale /
Commentary
Assumption(s)
Removal of Document Profiles
MVP
The new system must allow a user (subject to access permissions) to select one or more
existing versions of document profiles to be removed, to cater for circumstances in which a
document profile has been put onto the system in error. Removed versions of document
profiles must not be erased from the system entirely, merely hidden from future searches. The
removed versions must be retrievable by a limited set of users with sufficient access privileges
(such as system administrators).
Amendments and corrections to a document profile should be possible during the upload and
approval stages (see DOC 001 & 002 above). However, once loaded onto the system and
potentially viewed by system users these items (even those loaded in error) should not be
deleted entirely. This is because the Bank’s Record Management policy states that records of
both the Board and Executive Management committees are considered to be permanent records
of the Bank. Providing administrative users with the ability to hide specific versions of
document profiles, allows for those circumstances in which documents are loaded in error.
1. The remove version function would be restricted by role, assumed to be the same set of
users who approve the publication of document profiles
2. The retrieve removed versions of document profiles function would also be restricted
by role, assumed to be system administrators, RM&A and/or internal audit
Automated Reference Numbers
MVP
The new system should automate the allocation of document reference numbers to document
profiles to eliminate the risk of duplication and reduce the need for manual keying of data.
This requirement would mean a reduced chance for human error and a more efficient document
storage and publication process.
1. Assumes that the reference number can be generated in full or in part based on known
information (such as date, document type and the reference number of already stored
document profiles)
2. Some manual element may still need to be retained – such as recording whether the
document profile is entirely new, an addendum or a revision.
3. Consideration needs to be given that i) document profiles can be loaded by multiple
users at the same time and (see DOC 001) ii) there may be a pipeline of draft document
profiles awaiting amendment and approval prior to publication (see DOC 002)
Automated Creation of Document Cover Sheet
The new system should automatically generate and store document coversheets by populating a
pre-defined cover sheet template with document profile metadata. The system should provide
an automated function to merge the populated cover sheet and the physical file attachment(s)
together.
Document cover sheets provide useful factual and contextual information to the physical files
with basic information such as document title, reference number, outline summary and date.
However their current manual production is inefficient and is normally a duplication of the
information keyed into current applications as metadata.
1. It is assumed there will be more than 1 document cover sheet template required to cater
PUR1702/08
for all of the various types of document.
2. It is assumed that not all documents will require a cover sheet.
3. It is assumed all data required to populate the cover sheet templates will be entered as
document profile metadata such they will be completed automatically without manual
amendment.
4. Since the proposed entity relationship model allows for multiple physical file
documents per document profile, it can be assumed that the respective cover sheets
will be identical or near identical. It is assumed that in these circumstances the cover
sheet template will incorporate the ability to indicate how many related physical
documents there are for this single document profile and reference number (e.g.
document 1 of 3).
2.4 DOCUMENT RETRIEVAL
DOC 011
Description
Rationale /
Commentary
Assumption(s)
Simple Document Searching & Retrieval
MVP
The new system must provide an efficient mechanism for retrieving document profile records
via a simple search function that allows users to find documents via matching their reference
number or the text contained in their title or content of the physical file attachment(s). The
system must return search results quickly, sorting the results in date order, most recent first.
This requirement represents a need to retain a key existing feature of the current platform.
1. It is assumed that the display of search results will be capped at a maximum number
for system performance reasons.
2. The system must return the most recent results first.
3. Full visibility and access to the document profiles and attachments will be subject to
user access permissions. To avoid instances of reports of missing or lost documents, it
is expected that, in some circumstances, a stub of a document profile (including
reference number) should be visible to a user, even if they are not entitled to access the
full profile and/or file(s).
DOC 012
Description
Advanced Document Searching & Retrieval
MVP
The new system must provide an efficient mechanism for retrieving document profile records
via an advanced search function that allows users to find documents via entering a combination
of known attributes, including:
- Text contained in the title
- Reference number
- Date (with ability to specify an approximate range)
- Document type
- Text contained in the description / abstract or physical file attachment(s)
- Author
- The event type it was presented at (e.g. Board document vs ExCom document)
Rationale /
Commentary
This represents an enhancement to the current search capability through allowing users to
perform a more refined search based on a combination of known information. This would
allow for many useful search capabilities including the ability to return results for all
documents concerning a particular country of operation, presented to a specific committee
within a defined date range.
1. The full set of search criteria will be aligned with the requirements for document
profile metadata.
2. It is assumed that the display of search results will be capped at a maximum number
for system performance reasons.
3. The system must return the most recent results first.
Assumption(s)
PUR1702/08
4. Full visibility and access to the document profiles and attachments will be subject to
user access permissions. To avoid instances of reports of missing or lost documents, it
is expected that, in some circumstances, a stub of a document profile (including
reference number) should be visible to a user, even if they are not entitled to access the
full profile and/or file(s).
DOC 017
Description
Rationale /
Commentary
Assumption(s)
DOC 018
Description
Rationale /
Commentary
Assumption(s)
DOC 019
Description
Rationale /
Commentary
DOC 019
Description
Rationale /
Commentary
Notifications & Alerts
At the point a new document profile version is stored and made available to other users, the
new system should provide the option to issue a notification email to other, relevant users of
the system. By default, the system should issue the notification but provide the user who is
storing / approving the record with the ability to proceed without issuing a notification.
This requirement will automate what is currently a manual, inefficient process.
1. The notification email will contain only very basic information and a URL to the
record such that the user will need to be authenticated by the system before accessing
the document profile and potentially restricted content.
2. Relevant users of the users are assumed to be those registered users that will be able to
successfully access the profile record (i.e. have sufficient access privileges) and have
not altered their preferences/settings to disable notifications.
User Selected Alerts / Subscriptions
The new system should allow an individual user to define personal notification alert
preferences. At most a user should be able to receive alerts for all new document profile
versions that are in line with their access privileges but the system should also provide the
option to ‘unsubscribe’ from different types of notification. These setting should not affect
which profile records they can search for, retrieve and access.
This requirement would allow individual users to take control of the alerts they receive and
avoid becoming inundated with notifications for documents that they are not interested.
Notification types will need to be defined but are assumed to be linked to the document type
and the event type to which they are associated.
Bookmarked Profiles
The new system could allow an individual user to flag (or ‘bookmark’) any number of
document profile records. The system could allow the user to view a list of bookmarked profile
records to allow the efficient retrieval of records that are needed over multiple sessions or days.
The system could allow the user to subsequently remove the bookmarking flags from the
profile records.
A nice to have requirement that is expected to offer some usability benefits.
Favourite Document Searches
The new system could allow an individual user to save the parameters applied in the advanced
document search function for future use (as a ‘favourite search’). The system could allow the
user to efficiently re-apply the same search criteria again in future sessions.
A nice to have requirement that is expected to offer some usability benefits.
2.5 ELECTRONIC RECORD MANAGEMENT
RM 001
Description
Integrity of Records
MVP
The new system must allow for protection of the integrity of the documents and collections it
holds by protecting their authenticity, accuracy and completeness to the satisfaction of the
PUR1702/08
Rationale /
Commentary
prime holder of the records.
According to Bank policy:
In order to be authentic, a record must be one that can be proven:



to be what it purports to be;
to have been created or sent by the person who is purported to have created or sent it;
and
to have been created or sent at the time purported.
In order to be accurate, a record must be a full and accurate representation of the activities or
transactions that it documents.
In order to be complete, a record must have the content, context and structure required to allow
the reconstruction of the activities and transactions that it documents.
Assumption(s)
RM 002
Description
Rationale /
Commentary
1. All documents stored on the to-be system(s) will constitute a record and be subject to
this requirement.
2. Satisfying ourselves that a record is authentic and accurate will require the
combination of both adequate technology (for the provision of a suitable electronic
repository and submission process) and business procedure.
3. The decision on what constitutes an acceptable technology and procedural change to
reasonably ensure the authenticity and accuracy of records, sits with the prime holder
of the records. It is assumed that they will make this judgement having consulted with
RM&A, Information Security and IT.
Retention & Preservation of Records
MVP
The new system must only retain electronic information and document records for as long as
they are needed to support EBRD’s business functions/activities or legal obligations, as
described by the agreed retention schedules.
The system must preserve electronic information and document records for their entire lifecycle as specified in the Retention Schedules.
Mandatory Bank policy. The reasons for retaining records are to support policy formulation
and decision making; to document the Bank’s activities and decisions; to support the conduct
of the Bank’s activities; to enable the performance of the Bank’s obligations; to protect against
or support litigation; to comply with any applicable statutory or regulatory requirements and to
provide a corporate memory.
Retention Schedules prescribe:




Assumption(s)
the records for which the department/ unit is Prime Holder;
the length of time records are to be retained on-site;
when and for how long records are to be sent to, and be retained in, an off-site location;
and
when their final disposition - either destruction or permanent retention – is due.
1. It is assumed that the retention, preservation and disposition of records can be achieved
entirely electronically without the need for hard copy filing. To achieve this, records
should be delivered in a self-describing archival file format, as determined by RM&A.
It is assumed that PDF is considered to be an acceptable file format for these purposes.
It is noted that the Bank is considering the adoption of a new long-term preservation
policy. The impact of this new policy (for example the recommendation for alternative
archival file formats such as PDF/A) on the project will be considered as this policy is
finalised.
2. It is assumed that suitable electronic retention, preservation and disposition of records
can be achieved without duplicating the record (i.e. storing it in 1 place) provided that
RM&A are satisfied with the proposed repository or EDMS.
3. Most of the information and documents on the platform will require permanent
PUR1702/08
retention but it is assumed that this will not apply to all assets.
4. At least some of those assets which do not require permanent retention will require
active disposition.
5. The systems will not automatically dispose of these assets. Rather it is assumed that
RM&A will work with the business owners to agree a manual disposition of electronic
records via an administrative delete/remove function
6. Procedures for the preservation of electronic records must take account of the
obsolescence of hardware, software, file format and media formats used for storage of
electronic records and provide for alternate hardware, software, file format and media
formats to which the records can be migrated. The responsibility for identifying
systems soon to become outdated rests with IT. The decision whether to maintain the
outdated system, or to adopt a new system and migrate data into it, is taken by IT (or in
consultation with RM&A) and implemented by both departments.
RM 003
Description
Rationale /
Commentary
Assumption(s)
Protection of Vital Records Electronically
MVP
The Bank should ensure that vital records have physical protection from major disruptions such
as flood, fire, bomb, or computer failure through suitable electronic storage and back-up to the
satisfaction of the prime holder of the records. To achieve this, records should be delivered in a
self-describing archival file format, as determined by RM&A.
Mandatory Bank policy. If achieved electronically rather than through hard copy filing and
storage, this would represent a significant cost saving and represent an efficiency saving for
both secretariat and RM&A.
1. Not all documents stored on the to-be system will constitute a vital record and be
subject to this requirement.
2. The decision on what constitutes an acceptable technology and procedural change to
reasonably ensure the protection of records, sits with the prime holder of the records. It
is assumed that they will make this judgement having consulted with RM&A,
Information Security and IT.
3. It is assumed that PDF is considered to be an acceptable file format for these purposes.
It is noted that the Bank is considering the adoption of a new long-term preservation
policy. The impact of this new policy (for example the recommendation for alternative
archival file formats such as PDF/A) on the project will be considered as this policy is
finalised.
3.0 CALENDAR, EVENT & AGENDA RELATED REQUIREMENTS
3.1 EVENT PREPARATION
EVENTS 001
Description
Assumption(s)
Invitations
MVP
For every event, the new system must allow a user to have the option to invite any number of
other users. The invitation must include the following attributes:
- Title
- Starting date and time
- Finishing date and time
- Location
1. As well as the new system, this basic event data will also be held in both the new
Room Booking system and individual users’ personal diary/calendaring system. Where
possible, this common information will need to be synchronised to ensure there are no
contradictions
2. It is assumed that events will be created within the new system and a subset of the
PUR1702/08
event data sent to the Room Booking system and the users’ individual calendars
3. Only a small subset of the user base will be required to create new events and therefore
this function will almost certainly need to be restricted by role
4. It is assumed that event agenda items and documents will only be available to view via
the new application. Event invitations and diary appointments are therefore expected to
contain a link to the new system such that the invitee can navigate easily from basic
appointment to the latest event agenda and documents
5. It is assumed that events can be created and invitations sent without first being aware
of room availability, this is because i) Board and Executive Management committee
meetings will take priority over other bookings and ii) they are scheduled booked a
long time in advance
6. It is assumed that the sending of invitations can be done separately (i.e. later) to the act
of event creation. This allows flexibility in meeting administration
7. The list of invitees to any given event will be related to the associated Executive Body
membership (see below). However any given event can have 1 or additional invitees –
these could include for example minute takers, administrative staff or ‘guest’
presenters
EVENTS 002
Description
Rationale /
Commentary
EVENTS 003
Description
Assumption(s)
EVENTS 005
Description
Rationale /
Invitation Response Options
For every event, upon issue of a set of invitations the new system should allow a user to have
the option choosing whether or not to allow invitation responses. For those events where a
response is not required, the event should be added immediately to the recipient’s calendar
upon receipt of the invitation.
This function is useful for Board meetings (and other events with a pre-defined schedule) as the
organisation of these is not impacted by the availability of individual attendees. Having events
entered directly into a diary will also save time for the recipient.
Invitation Responses
MVP
For every event invitation for which the recipient has been granted the ability to respond, the
system(s) should:
- allow the recipient user to accept, tentatively accept or decline.
- add accepted, tentatively accepted and invitations pending response to the recipient’s
calendar/diary system (declined invitations should not be added)
- provide the inviting user with the status of every invitation response (accepted, tentatively
accepted, declined or yet to respond)
1. As well as the new system, this basic event data will also be held in both the new
Room Booking system and individual users’ personal diary/calendaring system. Where
possible, this common information will need to be synchronised to ensure there are no
contradictions.
2. It is assumed that events will be created within the new system and a subset of the
event data sent to the Room Booking system and the users’ individual calendars.
Default Information – Event Type
For each event type, the new system should allow a user to manage a set of default information.
This default information should be used to pre-populate any new unique event with this
information, but also allow this to be over-ridden by the event organiser. The attributes
available to be managed should be:
- Title
- Invitees (group and/or individual)
- Location
- Event items (draft agenda)
This is a valuable mechanism for ensuring efficient event organisation and would be equivalent
PUR1702/08
Commentary
Assumption(s)
to functionality available on the current applications
1. The systems should be able to support any current or future type of event involving 1
or more Bank staff, but at a minimum support the those event types managed by the
current platform:
o Board Meeting
o Board Steering Group Meeting
o Code of Conduct Committee Meeting
o FOPC Meeting
o BAAC Meeting
o Board Workshop
o Board Information Session
o ExCom Meeting
o MCom Meeting
o ALCom Meeting
o RiskCom Meeting
o SPCom Meeting
2. The systems will not support OpsCom or SBICom Meetings for the foreseeable future.
EVENTS 010
Description
Calendar View – Aggregated
MVP
The new system must provide the user with an aggregated calendar view (day, week or month)
of all event appointments in the system and filter according to a selection of one or more event
types. The ability to perform this function will be subject to access permissions, however the
user will not need to be either an invitee or organiser to view events in the calendar, i.e. the
new system must allow interested parties to be able to view event appointments in the system
of one or more event types.
This functionality will enable the user to view meetings relevant to the Bank’s Governance
structure to help their preparation and planning. This could be either as a meeting secretariat, as
a meeting attendee or as an interested party (either as Bank staff or external shareholder
representative). For example the user could select a view of Board meetings and then perhaps
add Board Committee meetings, Workshops, Information Sessions or Exec Mgmt Committee
meetings
1. The access restriction will not be a binary allowed/forbidden rather the event types will
also be restricted by role. E.g. The Board of Directors should not be able to view
Executive Mgmt Committee meetings
Rationale /
Commentary
Assumption(s)
EVENTS 011
Description
Rationale /
Commentary
Assumption(s)
EVENTS 012
Description
Assumption(s)
Calendar View – Export
MVP
The new system must allow the user to print their calendar view (either individual or
aggregated) without the need for manual formatting or editing
This functionality will enable an assistant to print a calendar for their boss and replicate the
existing platform’s Board Activity Planner functionality used by OSG
The system will export the calendar into a pdf view (or similar) to allow native printing via a
pdf reader / plug-in or equivalent
Event Cancellations
MVP
The system must allow an event organiser to cancel the event. The system must remove details
of the event from the system calendars. Cancelling the event must remove the link with any
associated document profile but must not remove the document profiles from the system.
1. As well as the new system, this basic event data will also be held in both the new
Room Booking system and individual users’ personal diary/calendaring system. Where
possible, this common information will need to be synchronised to ensure there are no
contradictions.
2. It is assumed that events will be created within the new system and a subset of the
PUR1702/08
event data sent to the Room Booking system and the users’ individual calendars.
3.2 EVENT INFORMATION SYNCHRONISATION
EVADMIN
010
Description
Rationale /
Commentary
Assumption(s)
EVADMIN
011
Description
Rationale /
Commentary
Assumption(s)
Synchronise Room Booking & Executive Body Calendars
MVP
The new system should ensure that the Executive Body calendars are synchronised with the
Bank’s new Room Booking system to avoid the potential for conflicting or out of date
information
This is an existing capability of the current applications, but is also a common sense
requirement to ensure there are no issues with event location/room bookings
1. Not all event information needs to be synchronised. The common information that
should be synchronised includes event name, date, start and finish times, contact point
and location/room
2. Detailed catering and audio/visual requirements associated with the event are assumed
to be held exclusively within the new Room Booking system
3. Documents, event items, and agenda items are assumed to be held exclusively within
the new system
Synchronise Individual & Executive Body Calendars
MVP
The new system should ensure that the Executive Body calendars are synchronised with the
relevant associated individual user calendar invitations and appointments
This is not possible with the current systems but would represent a significant efficiency
enhancement and reduce the potential for manual error and conflicting information.
1. Individual user meeting appointments and invitations are currently handled by
Microsoft Exchange. It is assumed that in the future state it will either remain
Microsoft Exchange or move to Office 365 Exchange
2. Not all event information needs to be synchronised. The common information that
should be synchronised includes event name, date, start and finish times, contact point
and location/room
3. Documents, event items, and agenda items are assumed to be held exclusively within
the new system
3.3 EVENT AGENDAS
AGENDA 001
Description
Assumption(s)
AGENDA 002
Description
Rationale /
Commentary
AGENDA 003
Event Agendas
MVP
The new system must grant the user the option to create and subsequently manage an agenda
for any given event. An agenda must contain an ordered set of event items.
Only a small subset of the user base will be required to create and manage event agendas and
so this function will need to be restricted by role.
Enhanced Item Attributes
The new system could allow the following additional optional attributes to be associated with
an event item:
- Presenter
- Expected start time
- Expected duration
These attributes will help the organiser with the detailed planning of the event particularly in
circumstances where the event has guest presenters or varying attendance throughout the event.
This situation is quite common for the review of projects at both the Board (and OpsCom)
Linking Event Items & Document Profiles
MVP
PUR1702/08
Description
Rationale /
Commentary
Assumption(s)
AGENDA 004
Description
Rationale /
Commentary
Assumption(s)
AGENDA 005
Description
Rationale /
Commentary
Assumption(s)
AGENDA 008
Description
Rationale /
Commentary
Assumption(s)
AGENDA 009
Description
Rationale /
The new system must grant the user the option to associate one or more document profiles with
an event item.
This is a replication of the existing behaviour of the current systems. It allows for the strict 1:1
relationship between items and document profiles currently applied in the Executive
Committee Organiser applications but allows for additional flexibility for circumstances in
which multiple document profiles are to be considered under a single event item.
1. Only a small subset of the user base will be required to create and manage event
agendas and so this function will need to be restricted by role.
2. Not all event items will have an associated document profile
3. Some event items will have links to multiple document profiles
Expected Linked Document Profiles
MVP
The new system should grant the user the option to indicate that a document profile is expected
to be associated with an event item, in circumstances where the document profile is not yet on
the system.
Event agendas can be prepared a long time in advance of the event itself, in these
circumstances the topics for discussion are often planned (with an outline agenda) but the
documents themselves may not be ready. This function will ensure that meeting attendees
know to expect a document
1. Not all event items will have an associated document profile
2. Some event items will have links to multiple document profiles
Agenda Update Notifications
The new system should allow a user to view the latest version of the event agenda at any given
time. Following an update to an event agenda, the system should provide the event organiser
with the option of whether or not to notify the event attendees of the change (rather than
automatically notify attendees of the change)
Event agendas can change frequently in preparation for an event. In all likelihood, an event
attendee is only likely to be interested in material changes to the event (dates and locations)
when the event is some time away. As the event becomes closer they are likely to be more
interested in more detailed changes (such as new documents, re-ordered agenda)
The notification is assumed to take the form of an email / calendar entry
Non-Document Related Agenda Items
The new system should grant the user the option to associate one or more hyperlinks with an
event item.
This functionality would enable event agendas to incorporate content from outside of the new
system and in electronic format rather than document form. This is expected to be either
publicly available information from the web or data / graphs from other Bank online systems
1. Only a small subset of the user base will be required to create and manage event
agendas and so this function will need to be restricted by role.
2. Not all event items will have an associated hyperlink
3. Some event items will have multiple hyperlinks
4. It is assumed that the links will either be to publicly available resources and sites on
the internet or to other Bank applications on the Strategic Extranet platform. In the case
of the latter, the Extranet Platform would handle any conflicts regarding access and
permissions
Live Event Updates
The new system could allow for the broadcast of live progress updates from events such that
event participants are aware of when any given event/agenda item is likely to begin.
Some longer events (such as Board meetings) have long agendas and participants who only
PUR1702/08
Commentary
Assumption(s)
need to attend for their particular agenda item. Historically this has been managed by admin /
secretariat staff sending a series of emails throughout the meeting. More recently, a freeform
text live progress feed has been trialled on the current platform.
1. A mechanism for broadcasting updates is considered sufficient (rather than 2-way
conversational functionality)
2. It is assumed to be entirely separate from event minute taking requirements
3. It is assumed that no restricted or sensitive information would be shared via the
broadcast (e.g. updates regarding discussion in the meeting or voting outcomes).
Therefore if a user has sufficient access privileges to view the event, they should also
have access to the live broadcast
4. The broadcast is assumed to be of interest to only a minority of users, and therefore
should be a function that they elect to join rather than receive by default
3.4 EVENT AND EVENT ITEM SEARCH AND RETREIVAL
EVENTS 013
Description
Event & Agenda Search & Retrieval
The new system should provide an efficient mechanism for retrieving historical and future
events (including ordered event items/agendas) via an advanced search function that allows
users to find documents via entering a combination of known attributes, including:
- Text contained in the event title or event item title
- Date (with ability to specify an approximate range)
- Event type (e.g. Board Meeting)
- Event item type (e.g. For Approval)
- Presenter
Rationale /
Commentary
This represents an enhancement to the current search capability through allowing users to
perform searches based on events and meeting agendas rather than merely documents. This
would allow for many useful search capabilities including the ability to return results where a
particular topic has been discussed or presented to a specific committee within a defined date
range.
1. The full set of search criteria will be aligned with the requirements for event and event
item metadata.
2. It is assumed that the display of search results will be capped at a maximum number
for system performance reasons.
3. The system must return the most recent results first.
4. Full visibility and access to the events, event items and related document profiles / files
will be subject to user access permissions. To avoid instances of reports of missing or
lost documents, it is expected that, in some circumstances, a stub of data should be
visible to a user, even if they are not entitled to access the full information and/or
file(s)
5. It is assumed this capability can be combined with the advanced document search such
that the user can retrieve events/agendas and/or document profiles using the same
search function
Assumption(s)
EVENTS 014
Description
Rationale /
Commentary
Assumption(s)
Favourite Event Searches
The new system could allow an individual user to save the parameters applied in the event
search function for future use (as a ‘favourite search’). The system could allow the user to
efficiently re-apply the same search criteria again in future sessions.
A nice to have requirement that is expected to offer some usability benefits.
1. It is assumed this capability can be combined with the advanced document search such
that the user can retrieve events/agendas and/or document profiles using the same
PUR1702/08
search function
4.0 MANAGEMENT OF EXECUTIVE BODIES REQUIREMENTS
BODY 001
Description
Rationale /
Commentary
Assumption(s)
BODY 002
Description
Rationale /
Commentary
Assumption(s)
BODY 003
Description
Executive Body Membership
MVP
The new system must be able to manage the membership of each of the system supported
Executive Bodies. For each body the system must allow the user to maintain details of the:
- Chair
- Members
- Alternates
- Secretariat
The system must publish this information such that it can be viewed by other system users.
In the case of the Board, the system must also be able to manage details regarding the
shareholder and constituency the director is representing
Storing this information allows for it to be published to interested parties. It also acts as an
enabler to i) part-automate the creation of event invitations more efficient and ii) store voting
records of an individual user
1. All members of all Executive Bodies will be users of the new system
2. An individual user can be a member of multiple Executive Bodies
3. Membership is mostly dictated by the user’s position within the Bank. However it is
assumed that Executive Body Membership will be managed manually by an
administrative system user
4. In the case of the Board, every member/alternate will represent a constituency. Every
constituency will contain 1 or more shareholders. A shareholder will belong to just 1
constituency
Historical Executive Body Membership
The new system should be able to manage effective dates against the membership of each of
the system supported Executive Bodies. As such the new system will be able to store and
publish historical information regarding any Executive Body’s Chair, Members, Alternates or
Secretariat.
Storing this information allows for it to be published to interested parties. It also acts as an
enabler to store voting records of an individual user
1. All members of all Executive Bodies will be users of the new system
2. An individual user can be a member of multiple Executive Bodies
3. Membership is mostly dictated by the user’s position within the Bank. However it is
assumed that Executive Body Membership will be managed manually by an
administrative system user
Executive Body Voting and Reporting
The new system should be able to manage the recording and reporting of both individual
member and overall votes against event items within selected (not all) Executive Body events.
In the case of the Board, the system should be able to identify the individual voting member
and each of the shareholders they are voting of behalf of.
When generating a report on historical voting records, the user should be able to filter based on
a combination of known attributes, including:
- Voting member / system user
- Shareholder
- Vote date (with ability to specify an approximate range)
PUR1702/08
-
Vote outcome (e.g. for or against)
Event type (e.g. Board Meeting)
Event item type (e.g. For Approval)
Text search based on event item title, document profile title, document reference
number or physical file title
Rationale /
Commentary
Assumption(s)
Voting outcomes is a matter of record for the Bank.
BODY 004
Description
Historical Event Reporting
The new system should allow for aggregated reporting regarding historical events across one or
more Executive Bodies. Data available for aggregated reporting should include:
- Event Type / Executive Body
- Attendance (including identification of event chairs, members and secretariats)
- Total and average duration
- Total and average number of event items
This reporting is required currently in the Bank but it is a time consuming activity to produce
Rationale /
Commentary
Assumption(s)
1. An individual vote record is assumed to be either – for, against or abstain
2. Not all Executive Bodies require formal votes to be recorded and those that do, will not
require votes to be recorded against all items in all events.
3. This functionality is expected to be only required at Board level initially but may be
extended
4. In the case of the Board, every member/alternate will represent a constituency. Every
constituency will contain 1 or more shareholders. A shareholder will belong to just 1
constituency. Each shareholder has a % share associated with it. This information
needs to be stored and maintained as an enabler for managing Board voting results
5. Access to voting history results and reports will be strictly limited by role
All required reporting data is assumed to have been captured in the system through earlier
requirements (i.e. there are no reporting specific data items)
5.0 MANAGEMENT OF SHAREHOLDER INFORMATION
SR 001
Description
Maintain and Update Shareholder Information
The future repository for shareholder relationship information must retain the following
existing key capabilities:










Retrieving information on an individual shareholder (or ‘country by country’) basis
[view access];
Retrieve the most recent voting history across all shareholders [view access];
Updating financial position information (including GDP) [edit access];
Updating EBRD membership (including shares, capital subscription and voting power)
[edit access];
Updating EBRD HR profile information (including % of total staff) [edit access];
Updating upcoming domestic election date(s) [edit access];
Updating profile information regarding the Governor, Constituency Director and
alternate representatives [edit access];
Edit existing and add new historical EBRD voting record items [edit access];
Add new voting record items in bulk (e.g. votes from multiple shareholders for the
same Board document) [edit access];
Edit existing and add new records of interaction between the representatives of the
Bank and government [edit access]; and
PUR1702/08

Rationale /
Commentary
Assumption(s)
SR 002
Description
This represents the desire to retain the key capabilities of the existing Shareholder Relationship
Portal (SRP) application on the new platform. The SRP application acts as a repository of
shareholder data maintained for the benefit of ExCom by the Bank’s Shareholder Relationship
Unit. The information, essentially stored at a ‘country’ level, includes statistics and information
regarding:
•
Financial position (including GDP);
•
EBRD membership (including shares, capital subscription and voting power);
•
HR profile at EBRD (including % of total staff);
•
Upcoming domestic election date(s);
•
Profile information regarding the Governor, Constituency Director and alternate
representatives;
•
Historical EBRD voting record (abstentions and votes against only); and
•
Past significant interactions between the representatives of the Bank and the
governments of non-countries of operation (calls, notes, correspondence and meetings).
The SRP maintains this information for all EBRD shareholders including countries of
operation, non-countries of operation, the EU and European Investment Bank. The information
is primarily used to brief and assist ExCom members and select other senior management
ahead of future visits or significant interactions with member country government
representatives. Any detailed data analysis or graphing is done outside of SRP.
1. The project will not develop material new capabilities or attempt to store additional
shareholder data items
2. Although the SRP is only used to store interactions with non-countries of operation,
the new repository should not enforce this restriction. The user should be able to add
interaction history with any shareholder.
3. There is no expectation of developing complicated functionality to allow or deny
concurrent access, editing and locking of data due to the very limited anticipated user
community.
4. The future repository for shareholder information won’t have any system integrations
with other Bank or public systems or data stores
5. Access to the information will be limited to a small number of staff (who will act as
administrators) and, potentially, members of ExCom (as per the current state).
6. Access will be granted on an individual named user basis to allow for access by
exception as required (e.g. for internal audit)
7. Role based permissions will be limited to granting and denial of access plus read only
or edit views. There is assumed to be no need for further restrictions. For example
there is no requirement for special administrative roles or functions and no requirement
to have access restrictions by country or jurisdiction.
Information Export / Print
The future repository for Shareholder Relationship Information should allow the user to export
the following information into a format (assumed to be Word compatible) that can be used to
form part of a briefing note or analysis paper for ExCom:



Rationale /
Commentary
Add new shareholder records [edit access].
Full information for a single, selected shareholder
List of upcoming elections across all shareholders, ordered by date
List of voting records across all shareholders, ordered by date
Generating the full briefing note and/or analysis paper will be done outside of the repository
(assumed to be in Microsoft Word) but the ability to include Shareholder information
efficiently without having to re-type is needed.
PUR1702/08
6.0 MANAGEMENT OF NUCLEAR SAFETY FUND INFORMATION
SR 001
Description
Maintain and Update Nuclear Safety Fund Information
The future repository for nuclear safety fund information must retain the following existing key
capabilities:



Rationale /
Commentary
Documents storage. Each physical document file will be stored along with the
following electronic metadata:
o Reference number
o Nuclear Safety Fund
o Date
o Type (e.g. Financial document vs Agenda vs Minutes vs Rules and Guidance)
o Title
o Content extract
o Information classification
Retrieving information and documents on a fund by fund basis [view access];
Document and metadata search and retrieval
This represents the desire to retain the key capabilities of the existing NSFnet application on
the new platform. The current NSFnet application is a repository for Nuclear Safety Fund
(NSF) related documents and has been used for more than 10 years. The system is used to
share information with ‘Fund Assemblies of Contributors’ (essentially fund donors and
external officials). For this reason the system, like BOLDnet, has both internal staff users and
external non-EBRD users.
The required functionality represents a subset of the capabilities required for the Board and
Executive Committee bodies described above. It is expected to be delivered through the set-up
a Nuclear Safety specific body and the simplification (ideally through configuration) of the
functional capabilities offered.
Assumption(s)
1. The project will not develop material new capabilities or attempt to store additional
nuclear safety data items
2. Nuclear Safety documents are not linked to events or agendas
3. Only members of the Nuclear Safety department staff submit and publish documents
so there is no need for a complex sign-off process
4. Unlike the other documents stored on the platform, NSFnet documents do not have
coversheets
5. There are no requirements for Nuclear Safety specific reporting / Management
Information capabilities
6. There is no requirement to integration with other Bank systems or publish information
publicly via www.ebrd.com
7. The list of external users for NSFnet (contributors) is different from the list of external
BOLDnet users (officials in shareholder capitals) though there is some overlap.
7.0 USER PERMISSIONS & INFORMATION SECURITY REQUIREMENTS
INF SEC 004
Description
User Permission Management
MVP
The new system must manage user access permissions that determine the system’s users ability
to perform key tasks including:
- Creation of a document profile / uploading of physical document file
- Reviewing, amending and approving draft document profiles
- Search and retrieval of document profiles and files
- Access to full individual document profiles and ability to open files
PUR1702/08
Rationale /
Commentary
Assumption(s)
INF SEC 005
Description
Rationale /
Commentary
Assumption(s)
Access to an Executive Body calendar, individual event or event item
Creation of an event, an event item or event invitation
Amending events or event agendas
Search and retrieval of events and event items
System reporting capabilities (including voting records)
Access permissions need to be sufficiently fine grained that users are only able to perform tasks
and view information to which they are entitled according to their role, the classification
(sensitivity) of the information and Bank policy.
1. Authentication of users will be handled by the Strategic Extranet platform. The new
system will be feed with basic information regarding the user which it must then grant
and manage system-specific access permissions
2. User access permissions will be managed in the new system using, in part, data
provided from other Bank systems. In particular, permissions will depend on the type
of user (e.g. are they Bank staff or an external user? If Bank staff, what department do
they belong to). This user type data will be provided to the new system from other
Bank identity and access management applications
3. Permissions are expected to vary according the executive body/bodies or event to
which the document profile belongs (e.g. a user may be entitled to see Board document
profiles but not Executive Management Committee profiles)
4. Permissions are expected to vary according to the Information Classification assigned
to an event item or document profile (e.g. a user may be entitled to see ‘public’ or
‘official use’ Board document profiles but not ‘restricted’ ‘highly restricted’ profiles)
5. Further permissions are expected to vary on a document by document basis, though
this is expected to be limited to only the most sensitive or ‘highly restricted’ profiles
(e.g. only named users A, B and C are entitled to view a given named document
profile)
6. The new system won’t attempt to restrict the users from printing opened physical
document files. If the user has sufficient access privileges to view a document profile
and open the file, it is expected that they will be able to print it
7. The system(s) won’t attempt to restrict the users from sharing opened physical
document files via email. If the user has sufficient access privileges to view a
document profile and open the file, it is expected that they will be able to share it
Document Secure Viewer Integration
The new system must integrate with a separate application that allows for the secure viewing of
highly sensitive physical document files. The new system must be able to identify both i)
which physical document files are considered to be highly sensitive and ii) which users are
entitled to view them. The user experience must be effective and efficient as the user navigates
between the new system and the separate ‘secure viewer’ application.
The secure viewing application is expected to enable the sharing of sensitive / highly restricted
documents electronically in a secure, fully auditable manner which will reduce the risk of data
leakage. This application will provide the Bank with the option to prescribe further restrictions
in terms of printing, downloading and sharing than is necessary for other classifications of
document. The new system needs only to be able to identify these documents such that they
can only be opened via this separate application and represents an extension of requirement
INF SEC 004.
1. User access permissions of who is entitled to open highly sensitive document files will
be managed will be held in the new system.
PUR1702/08
8.0 PAPER REDUCTION / MOBILE WORKING REQUIREMENTS
MOBILE 001
Description
Rationale /
Commentary
Assumption(s)
MOBILE 002
Description
Rationale /
Commentary
Assumption(s)
MOBILE 003
Tablet Device Compatibility
The new system must be compatible with the Bank’s selected model of tablet, such that a tablet
user is able to use all system functions on a tablet as effectively, or more effectively, than they
would be able to do on a desktop PC.
The system must allow the authenticated user to operate without an internet connection. When
a secure internet connection is restored, the system must synchronise to ensure the user has up
to date calendar, event and document information.
In order to reduce the amount of paper used in the running of Board and Executive Committee
events, it is considered important that event attendees are able to use a tablet device in meeting
and when travelling.
1. The Bank has not yet chosen a preferred model of tablet. It is assumed that the Bank
will support just a single model of tablet (at least initially) to ease the ongoing support
and maintenance responsibility
2. The user’s need to work offline and in particular the caching / offline review of
documents is assumed to necessitate the development and deployment of a native
tablet application
3. It is assumed that a very limited number of administrative, super-user or reporting
capabilities may require desktop usage. However all functions regarding event
preparation and document sharing must be both possible and effective via a tablet
device.
Mobile Device Compatibility
The new system must be compatible with the Bank’s selected model(s) of mobile telephone
plus compatible with other devices via the Bank’s selected Mobile Device Management
security platform, such that a mobile user is able to use the following key system functions on a
mobile as effectively, or more effectively, than they would be able to do on a desktop PC:
- View calendars, events and event items
- View document profiles and open files
- Receive and respond to event invitations, updates and cancellations
The system must allow the authenticated user to operate without an internet connection. When
a secure internet connection is restored, the system must synchronise to ensure the user has up
to date calendar, event and document information.
In order to reduce the amount of paper used in the running of Board and Executive Committee
events, it is considered important that event attendees are able to use a tablet device in meeting
and when travelling.
1. The Bank’s current mobile handset is Blackberry Leap. This may be subject to change
in the future.
2. The Bank’s current Mobile Device Management security platform is Good for
Enterprise. This may be subject to change in the future
3. The user’s need to work offline and in particular the caching / offline review of
documents is assumed to necessitate the development and deployment of a native
mobile application
4. It is assumed that document mark-up, administrative, super-user and reporting
capabilities will require desktop/tablet usage
Online Document Mark-Up
PUR1702/08
Description
Rationale /
Commentary
Assumption(s)
MOBILE 004
Description
Rationale /
Commentary
Assumption(s)
MOBILE 005
Description
Rationale /
Commentary
MOBILE 006
Description
The new system must allow the user to mark-up physical document files through:
- Addition of comments against a particular point in the document
- Addition of hand written notes and drawings (if using a tablet or mouse)
- Highlighting particular words or paragraphs or images
As such, the system allows for the creation of ‘personal’ versions of physical document files.
This is an essential requirement if a user is to prepare for events and review documents
electronically.
1. It is expected that the overwhelming majority of documents loaded into the system will
be in PDF format, though this may not be enforced
2. It is assumed that document mark-up many require desktop/tablet use rather than
mobile
Collaboration / Document Sharing
The new system should allow for the secure storage and retrieval of one or more personal
versions of a physical document file. The new system should allow the user to create a personal
version of physical document file on one device and retrieve it on another. The system should
allow the user to share a personal version of a physical document file with selected other
system users of their choosing.
Marking up documents and collaboration between individuals in a team is an important aspect
of event preparation. In particular advisers will often mark-up documents for their manager or
director. At Board level, collaboration on documents between staff in the constituency offices
and in capitals is an everyday occurrence. The system should enable this to continue whilst
limiting the potential for data leakage.
1. It is possible that expiry dates may apply to personal versions of document files since
permanent retention may not be necessary or desirable.
2. The individual user will need to select who they wish to share the document /
collaborate with. This group (e.g. the constituency office) is likely to remain relatively
consistent over time so the user experience should reflect this.
Electronic Meeting Packs
The new system should allow an event organiser to generate and publish a meeting pack file (a
single pdf file or similar) based on the event, agenda and linked document profile information.
The meeting pack should be effectively a merged file containing:
- Basic event details (title, start time, location)
- Agenda, with individual event item attributes
- All linked documents (physical document files, not document profile metadata)
The file should also have some level of indexing to ease navigation through a large document
This capability means that a recipient/event attendee doesn’t have to navigate between multiple
documents but instead scroll through a single file.
User Generated Electronic Meeting Packs
The new system could allow an individual user to be able to generate their own a meeting pack
file (a single pdf file or similar). The system could give the user the option to include/exclude
items and tailor their own meeting pack. The meeting pack would be effectively a merged file
containing:
- Basic event details (title, start time, location)
- Agenda, with individual event item attributes
- Selected linked documents (included by default, the user could be given the option to exclude
individual items)
- Additional documents (included either through selecting the document from the system, if
stored, or uploaded from the network, if not stored)
PUR1702/08
Rationale /
Commentary
Assumption(s)
The file should also have some level of indexing to ease navigation through a large document
This functionality would enable a user to prepare their own meeting packs, combining the
formal agenda and documents with their own prepared notes and memos
The user would have the ability to order the files in the pack so as to include their own markedup personal versions in between or instead of official agenda items and documents
9.0 DATA AND DOCUMENT MIGRATION REQUIREMENTS
MIGRATE
001
Description
Rationale /
Commentary
Assumption(s)
Migration of Data
MVP
The suppler must work alongside EBRD to ensure the successful migration of historical
physical document files plus document profile, event and agenda metadata from the existing
platform to the future state solution architecture.
The overwhelming majority of documents and data on the current platform represent
permanent records of the bank and must be retained.
1. The current platform is Lotus / IBM Domino
2. There are approximately 40,000 document profiles and physical files. It is assumed
that only a very small number of these won’t be migrated.
3. There are approximately 3,000 new document profiles and physical files added each
year
4. The historical metadata for documents and events will not match the requirements for
the to-be metadata so a mapping exercise will be required
5. It is assumed that only a limited amount of event data will be migrated (e.g. 1-3 years
of events)
PUR1702/08
APPENDIX B – ARCHITECTURE
This table describes architecturally significant decisions relating to the Pegasus solution.
Topic
Connectivity to
Office mail and
calendar service
Decision
Connectivity to the Office services will be via the Rest API.
The Pegasus application should provide a layer of indirection that
shields the solution from changes to the API
Rationale: The Office REST API is the standard approved method
provided by Microsoft for interacting with Office
Connectivity with
the Document
Management
Store
Connectivity to the Document Management Platform will be
implemented via the CMI-S API. The solution should include two
levels of indirection:
-
To shield from changes to the API
To shield from changes to the technology used to store the
document resources
Rationale: The CMI-S API is a standard used by content
management providers therefore it will make transitioning to
another vendor less challenging
Use of Backbase
CXP
The Pegasus application will be deployed within the new Backbase
CXP enterprise portal framework.
Rationale: The portal is the strategic platform for bespoke UI
development and it is also an essential part of the extranet strategy.
Access
Management
Both internal and external users will be authenticated via the
ForgeRock Open AM component which will is to be integrated
with Backbase CXP portal.
Rationale: This is part of the strategic extranet project
infrastructure which provides the basis for EBRD channel strategy
Use of the DevOps
infrastructure
The code should and the development should be compliant with the
DevOps infrastructure specifically should be packaged using
containers and deployed via the OpenShift infrastructure.
All the development should be hosted on the EBRD DevOps
infrastructure and will be subject to static code analysis and
assessed against the relevant metrics
Rationale: EBRD should retain the IP of the code
Workflow and
User Tasks
The Pegasus application will make use of the Unified Task
Manager solution for resolving user based activities. The UTM is a
custom built application which provides a single venue for
outstanding tasks and their resolution.
PUR1702/08
The primary use-case caters for the Pegasus application to generate
a Task request, send it to the Unified Task Manager and await a
response. The Unified Task Manager will assign an appropriate
workflow process to the task, where activities within the workflow
will be visible in the task lists of appropriately authorised users.
Once the workflow is complete, the information captured during
the workflow process is returned to the Pegasus application as the
response.
Rationale: The UTM is the strategic workflow tool
Unit Testing
Code should have a minimum of 70% unit test coverage. A test
first development approach is highly recommended
Rationale: Bugs and defect are likely to be significantly reduced
by using this approach
Separation of
Concerns
The Pegasus application should be split into modules that support a
specific concern (e.g. booking a room, interfacing with Outlook
365); each module should be independent from the other an
communication should be asynchronous and event based
Rationale: Minimize coupling and optimize resilience
Document
Metadata
Document metadata will be managed inside the Pegasus
application; the document management system will only have a
minimal set of tags required to mark a document as managed by
Pegasus.
Rationale: Minimize the coupling between the document
management system and the Pegasus application
PUR1702/08
Fig 1: Logical Data Model
PUR1702/08
Description
1
1. Backabase delivers the UI
which is built using HTML/CSS
and the Angular JS
framework
Backbase CXP
Angular JS
2. The business logic is built
using Java and Spring and it is
hosted in either Tomcat or
JBoss depending on
application requirements
Angular Material
O
p
n
e
A
M
Rest / Json
HTTPS
2
3. The persistence layer is built
using Hibernate and JDBC
6
Tomcat / JBoss
Rest
Email Server
7
Rest
Spring
Hibernate
8
3
5
JDBC
Rest
JMS
Room Booking
System
9
4
Views
SQL Server
SAP HR Database
Document Store
Tables
Fig 2: Pegasus Component Architecture
4. Transactional data is stored in
a relational database (oracle
or SQL Server); tables are
fronted by views for ease of
mantenance
5. The Document Store is
accessed via the CMIS API
Calendar information in the
6. email server is access via the
Rest based API
7. The Room Booking system is
access via a Rest based API
8. Forgerock OpenAM is used for
Access and Identity
management for both
Backbase and the java
container
9. The SAP HR database is
accessed using JMS and the
standard XML EBRD format
PUR1702/08
Description
1
1.
The portal hosts widgets and is
responsible for the integration
with security
2.
Widgets communicate with
application modules using JSON
over REST
3.
Application modules are hosted
inside Jboss or Tomcat depending
of container requirements
4.
Transactional data is stored inside
Oracle or SQL Server and in
extreme cases inside Hadoop
5.
The Visual Analytics module
displays data served by the Data
Warehouse
6.
The Data Warehouse is hosted
inside Oracle and Hadoop
7.
Legacy Cognos reports are served
by the Oracle based Data
Warehouse
8.
Application modules send and
receive events using the JMS
based Event Bus
9.
When a human task is required
application modules send an event
requesting user intervention
Enterprise Portal
Task List
Widget(s)
5
11
Application
Widget(s)
Application
Widget(s)
2
REST / JSON
REST / JSON
10
Transactional
Application
Module
Unified Task
Manager
Application
Widget(s)
REST / JSON
3
Visual Analytics
REST / JSON
Transactional
Application
Module
Transactional
Application
Module
6
Data Warehouse
(Hadoop)
4
SQL Server /
Oracle
JMS / XML
SQL Server /
Oracle
Hadoop
JMS / XML
7
Cognos
JMS / XML
9
8
Event Bus
Data Warehouse
(Oracle)
JMS / XML
10. The Unified Task Manager
responds to events requesting
human intervention by allocating a
workflow that embodies the
operating model for the task
resolution
11. The task list widget displays the
workflow steps that the user is
entitled to work on; each item will
open the appropriate application
widget
Fig 3: EBRD Application Architecture Overview
APPENDIX C – Quotation File
PUR1702_08_Quotat
ion file.xlsx
APPENDIX D – STANDARD CONTRACT
Standard contract
terms template (PUR1702_08).docx