(En anglais uniquement) This RFP concerns the provision of services to the UPU for the overhaul and migration to SharePoint 2019 and K2 5.4 of the Pegasus application (pegase.upu.int), which supports the production of documents in six languages.

The goal is that, by End December 2020, a completely revamped Pegasus application will be running in SharePoint 2019 and K2 5.4 on premises with standard support for the next three years, with training provided for users and all data migrated, including the history of PDOC requests, reference data and active workflow instances.

The deadline for submission of proposals is 7 September 2020 at 16.00 Central European Summer Time (CEST).

Q1: We have very strong K2 skills and are an official K2 partner. However, we do not have expertise in the new SharePoint 2019 Framework (SPFx) and Vue.JS at present, and it would take 3–4 months for us to obtain these skills. Is it worthwhile for us to participate in this bid, given that we have only K2 skills at the moment?

A1: If you have experience of Sharepoint 2016 and other JS Frameworks (e.g. React, Angular), it would be worth participating in the call for tenders, as at least 70% of the project will be performed on K2.

Q2: Would it be possible to perform certain parts of the project remotely (e.g. development, documentation, workshops)? Would the Vendor’s team be able to access the UPU development environment remotely? 

A2: Yes. The UPU can set up a development environment and grant remote access through an SSL VPN.

Q3: How many people should we plan to train? 

A3: Training should be provided for handover to our IT staff (four people) and the UPU will then organize internal training for advanced users. 

Q4: Who will be responsible for upgrading the Adlib application? 

A4: The UPU will upgrade Adlib.

Q5: Are you using Vue.JS for other applications at the UPU? Is this why you wish to use this particular front-end framework, instead of an alternative such as React or Angular?

A5: Vue and Vuetify are already used for other apps at the UPU. We are open to other JS frameworks, but Bidders will have to justify their choice.

Q6: Is the Pegasus solution integrated with, or based on, any third-party tools? If so, could you list them and inform us as to whether they are compatible with SharePoint 2019? 

A6: As described in the current topology diagram, Pegasus relies on the following components:

• SharePoint 2013 in 2010 compatibility mode;
• K2;
• Adlib (used to convert and merge documents into PDF via the Adlib connector for K2);
• myCat (Olanto concordance to align documents);
• Aspose.Words .NET library (used to generate the PDOC request tracking document);
• SSRS (used to generate reports).

MyCat will no longer be used and will be replaced by native SharePoint 2019 search capabilities (outside the scope of this RFP).

K2 5.4 supports SharePoint 2019.

Adlib will be migrated to v7 and deployed with K2 and SharePoint connectors.

SSRS in native mode is no longer supported in SharePoint 2019. We will use standard SSRS 2019 or Power BI for Pegasus reports.

Q7: Could you explain why the “pegase.upu.int”, “documents.upu.int” and “archives.upu.int” sites operate in 2010 compatibility mode? 

A7: Initially, these solutions were developed using SharePoint 2010 with custom .NET code (forms, custom APIs, etc.). The UPU decided to migrate these applications to SharePoint 2013 with 2010 compatibility mode for reasons relating to cost and timescale.

Q8: Is the myCAT application to be migrated? 

A8: No, myCAT will no longer be used and will be replaced by native SharePoint capabilities. This is outside the scope of this RFP.

Q9: How many users will there be? 

A9: There are around 300 internal users (i.e. staff members) who can submit PDOC requests in Pegasus. This includes around 50 users who process the PDOC requests (i.e. translators and typists).

Q10: Could you provide more detail as to what is meant by “Dynamic and low-level permission management on PDOC requests and related documents” (page 12 of the RFP)? 

A10: In the existing solution, working folders are created in SharePoint by the K2 process instance. We expect the K2 process instance to break inheritance and to update the permissions in SharePoint for PDOC request items and working folders, based on predefined rules. 

Q11: Are you using custom K2 brokers? If so, could you describe them? 

A11: The existing solution uses the following custom brokers:

• SQL Server to access metadata stored in databases (UPU bodies and meeting documents);
• 40 SmartBox Services to access metadata used in the workflow or forms.

We expect to move this metadata to SharePoint lists and/or a master database.

Q12: Are you using custom K2 controls? If so, could you describe them? 

A12: We do not use K2 smartforms in the existing solution. We use ASP.NET forms instead. 

Q13: Could you confirm that the existing application does not use any K2 smartforms and uses ASP.Net forms only?

A13: That is correct. All forms are ASP.NET forms and the existing solution does not use any K2 smartforms.

Q14: Are the K2 process instances initiated from the ASP.Net forms? 

A14: Yes. One main process is initiated when an ASP.Net form is submitted. Sub-processes are initiated via IPC (inter-process communication) events.

Q15: Are K2 smartforms your preferred solution for forms in the new application? 

A15: Yes. The objective is to leverage out-of-the-box SharePoint and K2 capabilities. However, a final decision will be taken during the design phase. An alternative solution based on JS forms may be proposed as an option. The cost for this alternative option must be included and clearly identified in the Bidder’s proposal.

Q16: Is the new solution to be used on an upgraded platform or a new platform? 

A16: A fresh K2 server will be installed. SharePoint 2019 is already running in the production, pre-production and development environments.

Q17: What do you mean by: “minimize technological dependence with greater modularity” (page 9 of the RFP)? 

A17: The UPU expects the Vendor to design a solution that is suitable for potential migration to the cloud version or future on-premises versions of SharePoint and K2.

Q18: How are K2 and SharePoint integrated with the existing application?

A18: Integration is via K2 connectors (SharePoint 2010, Adlib connector) and K2 web services.

Q19: We have very strong SharePoint skills and are an official Microsoft partner. However, we do not have K2 expertise. As most of the work relates to K2, are you willing to put us in contact with your preferred K2 partners? Is it worthwhile submitting a SharePoint-only proposal?

A19: We expect Bidders to have experience of both technologies and for their proposals to reflect this. We accept Bidders with experience of SharePoint 2016.

Q20: We have not been able to find development certifications for SharePoint 2016 and 2019, but there are infrastructure certifications for both of these products. Could you provide references for the required certifications?

A20: MCSD SharePoint Applications and MCSE SharePoint 2016. See www.microsoft.com/en-us/learning/sharepoint-training.aspx.

Q21: Who will host the code?

A21: The application and code will be developed and hosted on the UPU’s infrastructure.

Q22: With regard to management project, can we propose tools such as Azure DevOps?

A22: You may propose such tools. The UPU uses its own PPM tool (Sciforma).

Q23: With regard to deployment, can we use CI deployment?

A23: We are open to this possibility. Bidders should provide details of their deployment strategy in their proposals.

Q24: Do you use K2 or custom forms?

A24: The existing solution uses custom .NET forms. We plan to use K2 smartforms for the new solution, but Bidders may propose an alternative solution based on JS frameworks. In this case, Bidders should clearly indicate the costs for both solutions and justify their proposal (K2 smartforms vs custom JS forms).

Q25: Does your current solution incorporate any custom farm solutions, such as timer job or WSP?

A25: Yes – WSP farm solutions.

Q26: With regard to Adlib, is the requirement to create a new server or to reuse the existing one? Is this installation and/or configuration within the scope of the RFP?

A26: The Adlib server will be updated by the UPU. It will be an in-place update, so the existing configuration will be reused. The installation and update of the Adlib server are therefore outside the scope of the RFP.

Q27: We understand that the myCat concordancer is integrated into SharePoint via a custom solution. Could you provide a technical description of how this integration works? Is this installation and/or configuration within the scope of the RFP?

A27: The myCat concordancer is an open source solution integrated with SharePoint for searching documents for text alignment purposes. Further documentation is available at olanto.org/software/mycat/.

Within the existing solution, published documents are converted to text files, uploaded and indexed using the myCat concordancer. This takes place automatically via a K2 process. 

This component will be discontinued and replaced by native SharePoint search capabilities. This component is outside the scope of this RFP.

Q28: We understand that SharePoint publishing features should be used for several site collections, but that compliance with the new SharePoint 2019 user experience is also required. Is the use of SharePoint publishing features mandatory for these site collections?

A28: We plan to use the new team site template for the modern experience. Publishing features would be required if the UPU decides to apply a BindTuning theme to the new site. Bidders should indicate why this would be a constraint for the project.

Q29: How many development environments are provided by the UPU (i.e. how many developers can work simultaneously on the project)?

A29: We can prepare as many development environments as needed.

Q30: Why do you want to migrate the historical instances of K2 workflows? Is it only to obtain the associated documents or is there any other reason behind this?

A30: We expect at least active K2 instances to be migrated to ensure a better user experience and to avoid running two systems in parallel on two infrastructures. The migration of historical data is required for reporting purposes.

Q31: Can we propose another K2 migration scenario (e.g. parallel run), instead of migrating active workflow instances? Why do you need to migrate active workflow instances?

A31: Yes, you can propose an alternative scenario, provided that there is no extra cost for the UPU and that K2 supports this scenario. Active instances are linked to active requests. Requestors need, at the least, to be able to retrieve their active requests. 

Q32: If the Vendor is to be selected in mid-September, when do you expect to have a contract signed and an official start date for the project?

A32: We expect the contact to be signed by the end of September.

Q33: Is the deadline of the end of December absolute, or can we propose another deadline?

A33: The end of December is an absolute deadline, as the UPU does not want to renew extended support on K2 4.7. Bidders may propose an alternative deadline, but this must be justified.

Q34: With reference to section 4.3 of the RFP, can we assume that the upgrade of the document management system (documents.upu.int and archives.upu.int) is entirely under the responsibility of the UPU, and that the only link with Pegasus will be a call to the publishing form or process?

A34: That is correct.

Q35: Section 2.3 mentions the migration of existing SSRS reports to Power BI, but your answer to Q6 indicates SSRS 2019 or Power BI. Is Power BI mandatory?

A35: SSRS 2019 and Power BI are two possible options. Bidders should propose one of them, justify their choice, and ensure integration with SharePoint 2019.

Q36: Do reports have to be printable and/or mobile compatible?

A36: Yes, reports must be printable. It would be an advantage if they were also mobile compatible.

Q37: Can you confirm that licences (e.g. Power BI) do not need to be included in this proposal?

A37: The UPU is already licensed for all the components listed in the RFP (i.e. SharePoint 2019, K2, SQL Server, Adlib, BindTuning web parts). If Bidders propose other off-the-shelf components (e.g. JS frameworks, web parts, API subscriptions, .NET libraries) that are not listed in the RFP, the licensing costs should be included.