This RFP concerns the provision of consultancy services to the UPU for the recast and the migration to SharePoint 2019 and K2 5.4 of the application Pegase (pegase.upu.int) supporting the production of documents in six languages.

The goal is to get by Mai 31, 2021 a completely revamped Pegase application running in SharePoint 2019 and K2 5.4 on premise with standard support for the next 3 years, get users trained and all the data migrated including the history of PDOC requests, reference data and active workflow instances.

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

Q1: We would like to know why do you publish it again?

A1: UPU was not able to make a decision after the first call for tender. UPU decided to rework the RFP document and republish the call for tender. With the changes made in the RFP document, UPU expects to receive more offers and be able to respect the budgetary framework. 

Q2: Is it a sequel of the first tender or a pretty new (re) tender?

A2: It is the same call for tender. UPU was not able to make a decision after the first call for tender and decided to republish it.

Q3: Do you prefer that vendors should submit the proposal document in French or Spanish?

A3: If offer cannot be submitted in English, French is accepted but not Spanish.

Q4: Do you prefer French or Spanish as the primary language to be used for communication during the project execution?

 A4: Working languages during the project will French and/or English

Q5: Is it desirable to have French speaking members to be part of the vendors’ development team?

A5: Yes Q6: What is the preference of location for the vendor? Can we provide the services remotely from our India office?

A6: Due to Covid19 restriction, services will be provided remotely

Q7: Could you confirm that the usage of DevExpress framework is considered as an alternative to K2 SmartForms? Or do you expect us to use it on certains cases already identified by you (ex: on Document production planning table)?

A7: DevExpress will be used to develop new Webparts. We are open to use it as an alternative to K2 SmartForms but this has to be justified in the offer.

Q8: About UPU branding. do you expect the bidder to upgrade the existing UPU SharePoint and K2 themes?

 A8: Custom Sharepoint and K2 themes will be already available. UPU will develop a custom K2 theme following the guidelines provided by K2. UPU will buy and customize a theme from BindTuning.

Q9: How many user stories and test cases have been writtent about the existing application? Could you share some representative examples?

A9: User stories are being written based on functional specifications attached to the RFP. They will be ready by the start of the project.

Q10: Are you currently using distributed data storage of the Pegasus in the Microsoft SQL Server DB and SharePoint 2013?

A10: Yes. Please look at the current topology in the RFP. Pegasus Request metadata are stored in K2 database and documents metadata are stored in Sharepoint. All the DBs are in the same SQL instance.

Q11: Do you have the source code of all the custom web-parts of the Pegasus?

A11: Yes

Q12: Which ShareGate license are you using? With or without Nintex?

 A12: Without

Q13: Judging from the RFP, UPU will be responsible for production deployment.

Will Vendor be responsible for the deployment of DEV environment of SharePoint 2016 and SharePoint 2019 Server? This can be done by our team.

A13: Dev environment will be provisioned by UPU based on requirements from the vendor

Q14: According to RFP-2020-24-DPTC-Migration-of-the-application-Pegase-K2-Five-Sharepoint-2019.pdf, you are currently using Aspose.Words 15.9.

We have noticed that Aspose.Words is supported up to SharePoint 2016 only.

https://docs.aspose.com/words/sharepoint/

https://docs.aspose.com/words/sharepoint/introducing-aspose-words-for-sharepoint/

Shall we consider this for the Proposal or perhaps you have an alternative solution on this regard?

A14: UPU is open to replace Aspose.Words by an alternate solution based on native Sharepoint capabilities (Content type with word template), SSRS or DevExpress Office File API.

(These questions were raised during the publication of the call for tenders RFP-2020-017) and are repeated here for your information)

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 t