liu.se · Web viewLiU has annually about 1,500 incoming and outgoing students in various exchange...

Dnr LiU-2012-00765

Date June 21th 2012 Last day for submission of tender

August 17th 2012

Validity of tender November 17th 2012

Ref no: LiU-2012-00765 Procurement procedure

Open

INVITATION TO TENDER

You are hereby invited to submit a tender for a

Mobility System

to Linköping University, Sweden

according to the conditions stated in these contract documents.

1/27

Dnr LiU-2012-00765

1. GENERAL INFORMATION

IntroductionLinköping University's vision is to be an internationally distinguished university that is a driving force in a cosmopolitan region of knowledge. A part of this is our extensive student, teacher and staff mobility.

LiU has annually about 1,500 incoming and outgoing students in various exchange programs. Exchange agreements have been made with about 350 different universities around the world. Many of our teachers and staff members participate every year in various forms of exchange programs at our partner universities.

To manage the above mentioned mobility among students and staff a Mobility System will be procured by LiU. The system will be hosted by the Contractor as a Software-as-a-Service solution (SaaS). The system must be able to handle the following process flows and have the capacity to develop new process flows:

• be able to handle different types of incoming students, a minimum of 1700, from nomination and electronic application to their return home

• be able to handle different types of outgoing students (studies and placements), a minimum of 1000, from nomination and electronic application to their return home

• functions for student scholarship management, the Erasmus programme, as well as placements and any other form of scholarships

• be able to handle outgoing teachers and other staff, a minimum of 150

• management of different forms of grants, for example Erasmus grants linked to mobility

• agreement management – ability to handle different types of mobility agreements such as Erasmus and bilateral agreements, a minimum of 2000

The system should also have a function that supports Erasmus reporting, in accordance with EU requirements, to the National Agency.

1.1 CONTRACTING ENTITYLinköpings universitetSE-581 83 LinköpingSweden

2/27

Dnr LiU-2012-00765

1.1.1 Scope

Contract will be signed for a period of four (4) years with optional prolongation periods of four (4) plus two (2) years.

1.1.2 Contact personsName: Thomas MikiwerE-mail: [email protected]

If the tenderer wishes clarification of any aspect of the Contract documents, an enquiry must be submitted in writing directly to the contact person for this procurement, at such point of time that a response can be given six (6) days before the last day for tender submittal. Enquiries will be answered and published at http://www.liu.se/upphandlingar . The tenderer is solely responsible for obtaining complete documentation.

1.1.3 Additions/amendmentsComplementary additions/amendments will be announced at http://www.liu.se/upphandlingar.

1.2 CONTRACT DOCUMENTS1.2.1 List of documentsThe contract documents consist of the following documents and appendices: this document - administrative regulations, qualification of the tenderer and technical specifications, Appendix 1, Public contract (draft) Appendix 2, “Tender form/Declaration of truthfulness” Appendix 3, Price Appendix 4, List of Subcontractors

The tenderer is solely responsible for obtaining complete documentation according to this list of documents.

1.3 PROCUREMENT PROCEDUREThis is an open procurement procedure, in accordance with the Swedish law (SFS 2007:1091, chapter 4) of public procurements (LOU).

1.4 THE TENDER – FORMAL REQUIREMENTS

1.4.1 Validity of the tenderThe tender is valid provided that it is: signed by an authorized representative of the tendering company,

3/27

http://www.liu.se/upphandlingar

http://liu.se/upphandlingar

Dnr LiU-2012-00765

submitted no later than August 17th 2012. The tenderer is solely responsible for the timely arrival of the tender. A tender that arrives later than stipulated, may not be considered,

valid until November 17th 2012, which explicitly must be confirmed in the tender.

1.4.2 Formality of the tenderFormal requirements for the tenders are as follows: written in the Swedish or English language, submitted in a closed envelope/package marked with Tender and

reference number LiU-2012-00765. Please note that tenders submitted by delivery firms will need the outer packaging to bear the tender number also,

submitted in one (1) original and two (2) complete copies, submitted electronically on a CD or USB memory stick

Tenders submitted by fax or e-mail will not be accepted, since confidentiality cannot be guaranteed.

1.4.3 Submission of tenderThe tender can either be sent by post, by express or be delivered personally at the address stated below.

Visiting and express delivery address:Linköpings UniversitetRegistrator, Building Origo SE-581 83 LinköpingSweden

Mailing address:Linköpings Universitet RegistratorSE-581 83 LinköpingSweden

Office hours are Monday – Friday 09.00 – 15.00. There is a small mailbox outside the Origo building were tenders can be delivered, but it is very limited in size (27.5 cm * 3.5 cm). Keep in mind that tenders are submitted at the risk of the tenderer, and to ensure that the tender can be submitted correctly, the office hours should be taken into consideration.

A notification of reception will be sent upon formal opening of the tenders.

4/27

Dnr LiU-2012-00765

1.4.4 Disposition of the tenderTo ensure equal treatment and to facilitate assessment of tenders, the tenderer is requested to follow the order and numbering of this document. If no statement is made with respect to a requirement, the contracting entity is entitled to interpret this as the requirement is not fulfilled.

1.5 EVALUATION PROCESSBefore the evaluation process starts, the formal requirements are checked in accordance with 1.4. If any of those are not fulfilled, the tender in question may not be taken into consideration.

1.5.1 Qualification of the tendererThe requirements in section 2 are to ascertain that the tenderer has the necessary technical ability and capacity to fulfil the obligations concerning this public procurement. To qualify, these requirements have to be fulfilled.

1.5.2 ExaminationThe requirements indicated as “must” in chapter 3, will be checked. Only tenders that fulfill all these requirements will be evaluated further.

5/27

Dnr LiU-2012-00765

1.5.3 EvaluationThe public contract will be awarded to the economically most advantageous tender considering the award criteria below, listed in order of priority. Final weight for each criterion will be determined within the stated span at the time of evaluation.

Criteria Weight1. System performance 50 - 60 %

2. Delivery 20 - 30 %

3. Total price 10 - 20 %

Criterion: 1. System performance

The tenders will be evaluated regarding fulfillment of the “should”- requirements, and given points in accordance with the intervals stated at each requirement in the “System Requirements” chapter 3, part 3.1 – 3.16. The sum of achieved points will be compared with the maximum sum and multiplied with a factor as shown in the formula below:

P Sys=achived pointsmaximum points

×100

Criterion: 2. Delivery

The sum of achieved points in chapter 3, part 3.17 Delivery, will be compared with the maximum sum and multiplied with a factor as shown in the formula below:

P Del=achived pointsmaximum points

×100

6/27

Dnr LiU-2012-00765

Criterion: 3. Total price

Tenders will be ranked with regard to the lowest total price for year 1-4 offered according to appendix 3) Price.

The total price criterion will be differentiated in a scale of marks where highest mark, 100, is given for the lowest total price and the remaining tenders will be given marks in relation to the lowest price as stated below:

P price=lowest pricethe tender´s price

×100

Final resultThe total mark for each criterion will be weighted as stated above. The sum of the weighted marks, as in the formula below, will be the final total mark, which corresponds to the economically most advantageous tender.

PTOT = PSys × W Sys + PDel × W Del + PPrice × W Price

(P=Points, W=Weight)

1.6 COMMERCIAL SECRECYIn accordance with the Public Access to Information and Secrecy Act (SFS 2009:400 Offentlighets- och sekretesslag) all data pertaining to a procurement matter is subject to secrecy until an agreement has been entered into or procurement has otherwise been concluded.

Any data mentioned may be subject to secrecy even after the aforementioned time. Note, however that only in exceptional cases are data and prices according to the evaluation of the tender considered to be of such nature that they may be held secret for commercial reasons. With respect to commercial secrecy for the protection of a tenderer’s data, the requirement is that the data in question refers to the tenderer’s business- or service conditions and that there is a specific reason to presume that the tenderer will suffer damages if the data is disclosed.

If a tenderer considers the data submitted in connection with this procurement matter fulfils the aforementioned requirements for commercial secrecy, the tenderer must submit a request for commercial

7/27

Dnr LiU-2012-00765

secrecy, in writing; with clarification concerning the data referred to and what damage the tenderer would suffer if the data were disclosed.

The decision whether or not the data submitted by the tenderer fulfils the requirements for commercial secrecy will be made by the Contracting Entity.

1.7 NOTIFICATION OF DECISIONPrior to signing the public contract, notification of the contracting entity´s decision in this procurement matter will be sent in writing to all tendering companies.

An appeal for reconsideration of this decision may be made to Förvaltningsrätten (the Administrative Court) in Linköping. Such an appeal has to be sent within 10 days upon reception of the decision.

Address: Box 406, SE-581 04 Linköping, SwedenE-mail: [email protected]

1.8 AGREEMENTPlease note that there is no legally binding agreement until a public contract is signed by both parties.

2 QUALIFICATION OF THE TENDERER To ensure that the tenderer is suitable as a supplier for the specified procurement, the requirements below must be fulfilled.

2.1 LEGAL POSITIONAccording to the Swedish law of public procurement (LOU) the tenderer may not:

Be in bankruptcy or liquidation proceedings, under compulsory administration or subject to composition or have until further notice ceased making payments or be subject to trade prohibition. Be subject to filing for bankruptcy, compulsory liquidation,

compulsory administration, composition or other similar proceedings.

Have been found guilty of unprofessional conduct according to final and conclusive judgement.

Have been found guilty of serious wrongdoings in professional conduct. Have failed to fulfil liabilities concerning taxes and social fees.

Furthermore, checks are made that: The tenderer is registered in the companies’ register, commercial

register or similar register. The tenderer is registered for reporting and payment of taxes,

withheld preliminary tax and employer fees.

8/27

mailto:[email protected]

Dnr LiU-2012-00765

The tenderer must confirm that there are no grounds for exclusion according to the above, through provision of the documents mentioned below.

Tenderer located abroad The following national official documents must be enclosed to the tender:1) certificate of enrolment in a professional trade register,2) certificate that the tenderer has fulfilled obligations relating to the

payment of social security contributions,3) certificate that the tenderer has fulfilled obligations relating to the payment of taxes

Swedish tenderer Registreringsbevis from Bolagsverket must be enclosed. The purchaser may check with Skatteverket and Kronofogden regarding payment of taxes and social security contributions.

All tenderer The information must not be older than 3 months from last day for submission of tender. Appendix 2, “Tender form/Declaration of truthfulness” must also be signed and enclosed to the tender.

2.2 TECHNICAL ABILITY AND CAPACITYThe tender must include description of at least two (2) projects, identical or similar to this one, executed during the past five (5) years, including references specified with names and telephone numbers or e-mail addresses for contact persons.

2.3 SUBCONTRACTORSIf the tenderer intends to engage subcontractors to perform certain parts or services, these shall be stated, and specified in the tender. It is the tenderers responsibility that hired subcontractors comply with the terms and conditions in the contract. The tenderer is responsible for personnel of the subcontractor, as if it was their own staff.

9/27

Dnr LiU-2012-00765

3 SYSTEM REQUIREMENTSGeneral description of the Mobility system

To manage the mobility among students and staff a Mobility System will be procured by LiU. The system will be hosted by the Contractor as a Software-as-a-Service solution (SaaS). The following technical specifications describe requirements for the mobility system.

3.1 General

3.1.1FulfilledYes No

The system must be a fully developed standard system with the possibility of local customization to meet the different requirements of the four LiU faculties


The system must be able to be customized to and handle national and international laws regulating incoming and outgoing students, staff- and teacher mobility, agreement management, scholarship- and grant management

The system must be able to handle the following process flows and have the capacity to develop new process flows:


- The system must be able to handle different types of incoming students, a minimum of 1700, from nomination and electronic application to their return home


- The system must be able to handle different types of outgoing students (studies and placements), a minimum of 1000, from electronic application for the exchange programme and nomination, to their return home


- The system must have functions for student grant/scholarship management, the Erasmus programme, as well as placements and any other form of scholarships


- The system must be able to handle outgoing teachers

10/27

Dnr LiU-2012-00765

and other staff, a minimum of 150


- The system must support management of different forms of grants/scholarships, for example Erasmus grants linked to mobility

11/27

Dnr LiU-2012-00765


- The system must support agreement management – ability to handle different types of mobility agreements such as Erasmus and bilateral agreements, a minimum of 2000

3.1.9 (0–2 points)FulfilledYes No

The system should have a function that supports Erasmus reporting, in accordance with EU requirements, to the National Agency.Describe:

3.2 Web/Log-in


The system must have a web-based user interface and support the latest versions of: IE (currently 9), Mozilla Firefox (currently 11), Chrome (currently 18), Safari (currently 5).

3.2.2 (0-2 points)Fulfilled

The system should support following versions: IE 6, 7 and 8, Mozilla Firefox 9 and 10.

3.2.3Fulfilled

The system must have student and administrator access via web log-in

3.2.4Fulfilled

The system must allow for presentation of the exchange agreements/programmes with a search function on the LiU website (map)

3.2.5Fulfilled

The system’s web interface for presenting agreements must be able to be easily integrated within Linköping University’s regular web pages

3.3 System Administrator/Training


LiU system administrators must be able to administer and develop process flows

12/27

Dnr LiU-2012-00765

3.3.2 (0-6 points)FulfilledYes No

Following installation, LiU system administrators should be able to customize the web layouts according to our needs.Describe:

13/27

Dnr LiU-2012-00765


The system should allow for LiU system administrators to create, lock and open locked fields.Describe:


Training of system administrators must take place upon delivery.


Training of users should take place upon approved delivery.Describe:

3.4 Data/Documents


The system must be able to handle import and export of documents:- Microsoft Office package and PDF – Portable Document

Format


The system must be able to handle import and export of data in the following formats:- Excel, versions 2003 and 2010, i.e. xls and xlsx


The system should be able to handle import and export of data in the following formats:- Word, versions 2003 and 2010 (0-1 points)- Xml/xmlx (0-2 points)- Tab-delimited text (0-2 points)- Comma-separated text (0-2 points)


The system must be able to handle the uploading of document formats PDF and Word


The system should have a function allowing uploading of photos (picture format) in connection with applications


Electronic application forms must be available in the system and it should be possible to customize these locally.

14/27

Dnr LiU-2012-00765

The system must be able to handle uploading of any documents required for a complete application

15/27

Dnr LiU-2012-00765


By logging in to the system, the student should be able to monitor her/his application, i.e. see the actual status of the application.


The system should be able to handle administration and approval of applications electronically.


The system should be capable of confirming received applications and requesting supplementary information.


The system should be able to handle electronic signing of documents.


The system should be able to handle the filling out, completion and storage of learning agreements electronically.


The students should, upon log-in, be able to fill out/complete a learning agreement and later on possibly also request an update of the learning agreement. It should be possible for the responsible person to approve each update.Describe:


Study planning should be part of the system, to be filled out and updated electronically.Describe:


The system should be capable of handling students’ electronic applications for credit transfer, including any relevant supplementary documentation.Describe:


The system should be able to administrate credit transfer decisions and store these in the system.

16/27

Dnr LiU-2012-00765

3.5 System Capacity


The system must have sufficient capacity to handle logged-in users without interference.


The system must be able to handle 50 logged-in users, staff and administrators, simultaneously


The system must have sufficient capacity to handle simultaneous requests by students. 500 students must be able to be logged in simultaneously


The system must be able to handle scanned documents for 2500-3000 students, approx. 10 documents per student.

3.6 Technology


It must be possible to integrate the system with other systems at Linköping University


The API should be based (in order of preference) on rest with JSON or XLM, SOAP or other custom XML-based format


The contractor must provide operation and support of the system


The system must support authentication using Microsoft Active Directory


The service must support TLS Transport Layer Security


The service should support externalized authentication using SAML2 or equivalent

17/27

Dnr LiU-2012-00765


The system should be able to use Microsoft BizTalk.


The system must not require installation of client software in order to be used


The system should have a graphic user interface format so that the users do not have to scroll horizontally on most computers and iPads.


Roles and authorizations must be able to be set flexibly in the system (for example reading rights in certain parts for certain roles, writing rights for other roles)


The system should have a log function for administrators, showing who did what and when.


The system should have an API allowing uploading of photos (picture format) for applicants.

3.7 Other


The contractor should describe the way in which they intend to take responsibility for and support LiU’s continuous adjustment of the solution in relation to national and international laws and agreements regulating the management of incoming and outgoing students, staff- and teacher mobility, agreement management, scholarship- and grant management.

Describe:


The system should be able to link to social media, such as Twitter.


The system should run on an annual basis and an academic-year basis, for example 2012/2013, with the possibility of further breakdown into smaller time units, such as semesters, parts of semesters, or weeks.

18/27

Dnr LiU-2012-00765


Already at the application stage, the system should allow for breakdown by faculty, programme etc.


The system should be able to handle different application deadlines, application periods and categories.


The system should be able to handle incoming teacher/staff.


The system should be able to handle whether or not students are applying for accommodation.


The system should be able to distinguish different categories of students like incoming from outgoing students and exchange students from Free mover students.

3.8 Nominations


The system should be able to handle nominations/admissions of incoming and outgoing students as well as teachers and staff mobility in accordance with the applicable agreement. The nomination/admission should be linked to the correct agreement, after which the system should count down so that it is possible to see how many places remain within the agreement. Describe:


The system should be able to keep count of incoming and outgoing student’s length of study and link it to the applicable agreement, after which the system should count down so that it is possible to see the remaining time for exchanges within the agreement.


It should be possible within the system to accept or decline placements/nominations.

3.9 Evaluation/Statistics

19/27

Dnr LiU-2012-00765


The system must contain an evaluation part


It should be possible for students, teacher and staff to write mobility reports in accordance with EU requirements.


A requirement regarding the evaluation part (mobility reports) is that it should be possible to extract data from the evaluation part for follow-up/statistics.


The system should have a statistics feature for annual reports and follow-ups.

3.10 Support


It must be possible to procure the support service


The contractor should provide online support between 08.00 and 20.00 weekdays CET. If not, the periods that support can be provided should be specified.Specify:


The system should provide help texts, in English, in the system.

3.11 Agreements


The system should contain a function to signal different events, for instance a reminder when agreements are coming to a close.


The system must be able to handle different templates for documents and agreements, including links to different fields in the system


The system must have sufficient number of fields with

20/27

Dnr LiU-2012-00765

information to support the administration of agreements

3.12 Fields


The system should contain a minimum of 3 different student contact details for, address, telephone and email.


The system should contain a minimum of 6 different contact details for liaisons with partner universities, address, telephone and email.


The system should contain free-text fields in each process


The system should contain contact details (fact sheets) about LiU as a partner university.


The system should have elective mandatory fields, for instance in application forms.


The system should be able to handle connections between different fields within the system, such as between agreement and student, grant and student/teacher.


The system should have a field for the agreement number that should be unique for each agreement.

3.13 Email Functions/Searches


The system should provide advanced email functions like settings for programmable emails


The system should be able to send emails (email lists) to multiple recipients on the basis of a predefined search in the system


The system should be able to send emails containing attached files, files that exist within the system and files

21/27

Dnr LiU-2012-00765

that are created from information saved in the system.


The system should be able to send emails to one or more recipients, with personal settings, including personal information.


The system should have advanced search functions in all fields of the system


It should be possible to save frequently used search combinations.


The system should provide support for extracting standard statistics, such as monthly reports.

22/27

Dnr LiU-2012-00765

3.14 Outgoing/Scholarships


The system should contain a search function for outgoing students and outgoing teachers/staff that is linked to their competence and academic field. This to allow students and teachers/staff to only view the agreements and information about the exchange that are of personal relevance to them. Describe:


The system should contain the following search terms for outgoing students, in order to identify relevant agreements:

• country• programme• subject• exchange programme (Erasmus, Nordplus, placements and more)• general agreements• student exchange (on Bachelor, Master and Doctoral level)• teacher exchange• language• agreement area• DD = double degrees


The system should be able to handle the currencies Euro and SEK with regard to Erasmus funding (agreement, placement, staff- and teacher mobility).

3.15 LADOK Study Administration


The system should have a number of fields that correspond to tables in LADOK (the study administration system). Field number 1-20.


Field number 14-20 should be fields with complex context according to the listed examples.


It should be possible to import and export data from field

23/27

Dnr LiU-2012-00765

number 1-20 to and from LADOK and the system.The above requirements applies to the following fields:

1. referenser number2. personal identity number/interim number3. first name4. last name5. date of birth6. gender7. c/o address8. street address9. city10. post code/zip code11. country12. email address13. telephone number14. exchange programme – the exchange programme must

be a valid exchange programme code in LADOK15. semester from – semester is written as ‘Hnn’ (autumn

semester) or ‘Vnn’ (spring semester), where ‘nn’ is the year, for example H12 or V11

16. semester to – semester is written as ‘Hnn’ (autumn semester) or ‘Vnn’ (spring semester), where ‘nn’ is the year, for example H12 or V11

17. university code – the university code must be a valid university code in LADOK

18. country – the country code must be a valid country code in LADOK

19. department – the department must be a valid department code in LADOK

20. coordinator – coordinator must be a valid code in LADOK and be linked to a department in LADOK

Examples for fields number 14, 17, 18, 19, 20Exchange programme, 10 character, example "T_ERASMUS","F-FREE-MOV"University code, 11 character, example "AACHEN01", "ADELAIDE01"Country, 4 character, example "DE", "GB","AU"Department, 4 character, example "IFM", "TEMA"Coordinator, 4 character, exempel "LHÅG"


When a student is registered in LADOK the mobility system should receive a signal of the registration.Describe:


The system should be able to transfer pre-selected courses that the student has been admitted to from the system to

24/27

Dnr LiU-2012-00765

LADOK. Describe:

3.16 Service Level Agreement (SLA)


Tenderers should provide the basis for a Service Level Agreement (SLA) that will be included as an appendix to the Public contract.Specify:

25/27

Dnr LiU-2012-00765

3.17 Delivery


Delivery of a fully developed standard system must take place four weeks after the agreement is signed.


Delivery of a fully implemented and working system should take place at the latest on the 31th of December 2012.Specify delivery date:


The implementation process is vital to secure that the system is up and running at desired date. The tender should include a detailed project plan with a timeline for the implementation. The project plan should, among other things include:- Resource Plan- Schedule with time-bound activities- Commitments expected from LiU

3.18 Price


The tender must include the price for a complete SaaS system solution including implementation according to appendix 3 Price

3.19 Payment terms


The first annual license fee and the cost for the implementation must not be invoiced before the delivery approval according to the Public contract subsection 4.2.

For future years, the annual license fee may be invoiced annually in advance.

Other development that has been ordered separately by LiU may be invoiced afterwards on a monthly basis.

All payments are to be against invoice 30 days net.

3.20 Public contract

26/27

Dnr LiU-2012-00765

3.20.1The draft of the public contract

Appendix 1) Public contract (draft), are presumed to form the basis for an agreement between the parties.Comments:

27/27

liu.se · Web viewLiU has annually about 1,500 incoming and outgoing students in various exchange...

Documents

Transcript of liu.se · Web viewLiU has annually about 1,500 incoming and outgoing students in various exchange...