تجاوز إلى المحتوى الرئيسي

Workflow Management System

  1. Objectives and desired results

 

    1. General objective

       The Central Inspection (CI) aims to acquire and implement a modern, secure, and user-friendly off-the-shelf (OTS) Workflow Management System (WMS) to automate and optimize business processes, enhance service delivery to public entities, boost efficiency, and ensure adherence to internal standards. The system will be hosted on-premises and must comply with specific functional and technical requirements. SaaS or cloud-based solutions will not be accepted, and the system must come with a perpetual license.

 

    1. Specific objectives
    • Automate manual workflows to enhance productivity.
    • Ensure consistency in processes across departments (Available Document Management System, and others).
    • Improve collaboration and communication between CI directorates as well as public entities that are under CI jurisdiction.
    • Reduce turnaround time for tasks and approvals.
    • Provide audit trails and reporting for workflow analysis.

 

    1. Anticipated results

Delivery of the required needed solution by October 31st, 2025.

 

  1. Deliverables

 

    1. Scope of Work

The selected Vendor will be responsible for:

  • System Design and Development: Based on Annex 1 workflows, the vendor will configure and/or develop these workflows with their related user interfaces, and any necessary integrations.
  • Installation and Setup: The vendor will be responsible for installing the WMS on the provided by vendor on-premises servers, ensuring it operates optimally within the CIB’s IT infrastructure.
  • Testing: Comprehensive testing, including functional, user acceptance, and performance testing, must be conducted to ensure the system meets the CIB’s needs.
  • Training and Documentation: The vendor will provide training sessions for end users, administrators, and IT staff. Documentation (user manuals, admin guides, etc.) must also be provided.
  • Post-Implementation Support: The vendor must offer onsite (no remote offerings are accepted nor considered) support services during the transition period and provide onsite (no remote offering is accepted nor considered) ongoing maintenance for 3 years, starting from the sign off date, ensuring the system’s stability.
  • Providing Technical Support for CIB Portal Integration: Post the solution deployment and sign off, CIB shall seek the services of a Professional Web Development company to add pages to their website enabling public entities and the public to trigger and/or track certain workflows online. The vendor is bound to work with the web development company by supporting this endeavor through the following actions:
    • Provide API documentation on how to securely access the workflows using its ID and/or any other parameter(s) and returning specific workflow information such as status and stage.
    • Work hand in hand with the web development company in customizing if needed any API.
    • Provide detailed information and needed support on enabling webhooks thus allowing certain pages to trigger, from the online site, certain workflows.

 

 

    1. System Requirements

 

Functional Requirements

  •    OTS: the proposed solution must be an Off the shelf one yet allowing granular customization using a user-friendly drag and drop approach.
  •    Web-Based Interface: The system must be accessible through a web browser and support all major browsers (e.g., Chrome, Firefox, Edge).
  • UI: The System UI language must be 100% in Arabic thus all functionalities must be provided using an Arabic Interface. Other suggested UI languages are not accepted nor will be considered.
  • Workflow Automation: The system must allow authorized users to define, manage, and automate workflows with customizable business rules, approvals, notifications, and escalations using drag and drop schemes and with zero to no code approach. Below are the must have, shipped out of the box, automation requirements:
    • Visual Workflow Designer: A user-friendly interface for designing workflows using drag-and-drop functionality.
    • Templates and Pre-built Workflows: Ready-to-use templates for common processes to speed up implementation.
    • Customizable Workflow Steps: Ability to define specific tasks, conditions, and decision points in the workflow.
    • Automated Task Assignment: Automatically assign tasks to team members based on predefined rules or roles.
    • Due Date and Reminder Notifications: Automatic alerts and reminders for approaching deadlines to keep tasks on track.
    • Recurring Tasks Management: Set up tasks that need to be performed regularly without manual input.
    • Dynamic Workflow Adjustments: Ability to modify workflows on the fly in response to changing business needs.
  • User Roles and Permissions: It must provide robust role-based access control to ensure data security and appropriate access to workflows.
  • Automated Approval Workflows: Define steps for review and approval, with notifications for required actions.
  • Escalation Procedures: Automated escalation of tasks or approvals to higher authorities if not completed in a timely manner.
  • Integration Capability: The WMS should integrate with existing CIB systems (DMS: document management system and archiving, CIB official Web Portal) for seamless information exchange.
  • Real-time Collaboration: Features for CIB members to communicate, comment, and share files within the workflow.
  • Audit Trails and Reporting: The system should provide detailed logs of all workflow actions and generate reports for analysis.
  • Document Management: The system must be capable of storing and managing documents related to workflows into the CIB document management system
  • Notifications: Automated email notifications for task assignments, approvals, and escalations.
  • Scalability: The WMS should be scalable to accommodate growth in users, workflows, and data volume.
  • Mobile Compatibility: Access workflows and tasks from mobile devices to enable work on the go.
  • Mobile Notifications (Highly desired): Alerts and updates sent to mobile devices for real-time communication.
  • Predictive Analytics (Highly desired): AI usage to analyze workflow data and provide insights for future improvements.
  • Automated Decision-Making (Highly desired): Ability to implement AI-driven decision points to streamline processes.
  • Open API and Webhooks: The system must provide out of the box functionality for Open API and Webhooks adhering to the below requirements:

Open Secure API:

    • Authentication & Authorization: The API must support OAuth 2.0 or equivalent secure authentication protocols to ensure only authorized external systems and users can access and interact with the system.
    • Encryption: All API communications must be encrypted using HTTPS (SSL/TLS) to ensure secure data transfer and prevent unauthorized interception or tampering.
    • Rate Limiting & Throttling: Implement rate-limiting mechanisms to protect the system from abuse and maintain performance during high-traffic periods. Define appropriate API request limits based on user roles and subscription levels.
    • API Documentation: Comprehensive documentation must be provided, detailing available endpoints, request/response formats, error codes, and usage examples. This will help developers integrate external systems efficiently.
    • Monitoring & Logging: The system must provide robust logging and monitoring features for API usage, enabling administrators to audit access, track performance, and detect potential security threats.
    • Error Handling & Response Codes: The API must consistently provide meaningful error codes and messages to facilitate troubleshooting and error recovery by external developers.

                                           Webhooks Requirements:

    • Webhook Security: Webhooks must use secret tokens or HMAC signatures to authenticate payloads, ensuring the data is sent by a trusted source and preventing unauthorized or malicious attempts.
    • Event Customization: The system should allow users to customize which events trigger webhook notifications, ensuring they receive only the relevant data and minimizing unnecessary data transmission.
    • Retries & Failure Handling: Webhooks should be equipped with a retry mechanism, including exponential backoff, to ensure reliable delivery in case of failures or interruptions in connectivity.
    • Webhook Management Interface: The system must provide a user-friendly interface for configuring, testing, and managing webhook subscriptions. This interface should allow users to enable/disable webhooks, manage secret keys, and view delivery logs.
    • Payload Structure: Webhook payloads must follow a standardized, easily-parsable format such as JSON, and should include relevant metadata that allows recipients to take appropriate actions.
    • Webhook Rate Limiting: Implement rate limits for webhook notifications to avoid overwhelming external servers and ensure that the system remains stable during high volumes of webhook activity.

                

                 Nonfunctional requirements

 

                    A - Performance Requirements

  • System Response Time: The system should respond to user inputs and API requests within 2-3 seconds for typical operations and under 5 seconds for complex workflows.
  • Scalability: The system must scale horizontally to handle increasing numbers of users, workflows, and data without degradation in performance, ensuring continued usability as the organization grows.
  • Throughput: The system should handle a minimum of 50 concurrent workflows per second, with provisions for higher volumes depending on usage patterns and load.

 

 

 

B -   Reliability & Availability Requirements

  • Uptime: The system must have an uptime of 99.9% or higher, ensuring that workflows are always available and running smoothly, with minimal downtime.
  • Fault Tolerance: The system should be able to handle component failures (e.g., server outages) without crashing. Redundancy mechanisms should be in place to ensure continuity of service.
  • Data Backup & Recovery: Automated daily backups must be implemented to protect against data loss, and the system should support recovery within a maximum of 1 hour in case of failure.

 

C - Security Requirements

  • Authentication & Authorization: The system must support role-based access control (RBAC) and multi-factor authentication (MFA) to ensure that only authorized users can access specific workflows and sensitive data. Out of the box support for LDAP is mandatory.
  • Data Encryption: All sensitive data, including user credentials, workflow information, and communication between the system and external services (via API/Webhooks), must be encrypted both at rest and in transit.
  • Audit Logs: The system must maintain detailed audit logs for all user activities, changes to workflows, and integrations. These logs should be tamper-resistant and retained for compliance with security policies.

 

D - Maintainability & Extensibility Requirements

  • Modularity: The system must be built using modular architecture to ensure that individual components (e.g., workflow engine, integration modules) can be updated, maintained, or replaced without affecting the entire system.
  • Documentation: Detailed technical and user documentation must be provided, including guides for installation, configuration, API usage, and troubleshooting.
  • Extensibility: The system must support the easy addition of new features, workflow templates, and third-party integrations without significant changes to the core architecture.

 

E - Interoperability Requirements

  • API Compatibility: The system must be compatible with industry-standard protocols (e.g., REST, SOAP) for API integrations, enabling seamless connectivity with other enterprise systems (e.g : CIB archiving system)
  • Data Import/Export: The system must support importing and exporting data in common formats (e.g., CSV, JSON, XML) to ensure interoperability with external tools and legacy systems.

 

F - Availability and Disaster Recovery Requirements

  • Disaster Recovery: The system must include a disaster recovery plan, with failover mechanisms and backup strategies to ensure continuity in case of a major outage or disaster.
  • High Availability Architecture: The architecture should support load balancing, clustering, and failover capabilities to maintain high availability even during peak usage or hardware failures.

 

 

CIB workflows implementation

 

 The listed in Annex 1 workflows are integral to the system’s functionality and must be incorporated in their entirety, adhering to the specifications outlined in the annex.

  The Vendor must ensure that:

 

  • Full Implementation: All workflows suggested by CIB are fully integrated into the system and operational upon delivery.
  • Compliance: The workflows must meet the technical and functional requirements set out in this document and Annex 1.
  • Customization: The Vendor is responsible for making any necessary customizations or modifications to ensure that the system aligns with CIB’s specific operational needs.
  • Testing and Validation: The Vendor must provide adequate testing and validation to ensure that each workflow operates as intended and meets the agreed-upon criteria for performance and usability

 

Deployment and Licensing

 

  • On-Premises deployment: The WMS must be deployed in the CIB Data Centre, and no cloud-based services should be suggested nor involved directly or indirectly. The provider must suggest and provide appropriate Hardware and Operating system that best fit its proposed solution.
  • Perpetual Licensing: The WMS licensing must be perpetual, ensuring no recurring license costs. SaaS offerings will not be considered. 50 end users’ licenses are required + 2 super users (administrators licenses) – Total: 52.

 

    1. Agile Methodology and Sprint Delivery requirements

                         CIB requires the selected Vendor to utilize Agile methodology for the development and delivery of the analytics dashboard project. Agile methodology promotes iterative development, collaboration, and flexibility, allowing for rapid adaptation to changing requirements and stakeholder feedback. Additionally, the Vendor is expected to adhere to a two-week sprint delivery cycle, where each sprint spans a duration of two weeks. This approach enables incremental delivery of functionality, early validation of features, and continuous improvement throughout the project lifecycle.

 

Agile Methodology Implementation

The Vendor shall adopt Agile principles, practices, and processes for the development, delivery, and maintenance of the Portal with all its features.

Stakeholder involvement and feedback shall be solicited throughout the development process to ensure alignment with business objectives and user needs.

 

Two-Week Sprint Delivery

       The Vendor shall commit to a two-week sprint delivery cycle, with each sprint comprising planning, development, testing, and review activities.

       Sprint planning sessions shall be conducted at the beginning of each sprint to select and prioritize user stories or features for implementation.

       The development team shall deliver a demonstrable increment of functionality at the end of each sprint, adhering to the agreed-upon scope and acceptance criteria.

 

    1. Project Plan 

 

As part of the technical proposal submission, we require from the selected Vendor to include a detailed project plan outlining the approach, timeline, milestones, and deliverables for the development of the portal. The project plan serves as a roadmap for project execution, providing clarity on project scope, resource allocation, and project dependencies. The following requirements apply to the submission of the project plan.

  Comprehensive Overview

•     The project plan shall provide a comprehensive overview of the project, including the objectives, scope, and high-level requirements.

•     It shall outline the proposed solution architecture, technologies, and methodologies to be used in developing the analytics dashboard

Timeline and Milestones

•     The project plan shall include a detailed timeline with specific milestones, deliverables, and dependencies identified for each phase of the project.

•     Milestones should align with key project activities such as requirements gathering, design, development, testing, deployment, and training.

  Resource Allocation

•     The project plan shall specify the resources required for each project phase, including personnel, hardware, software, and any other necessary resources.

•     It shall identify roles and responsibilities for project team members, stakeholders, and any external parties involved in the project.

Risk Management

•     The project plan shall address risk management strategies, including identification, assessment, mitigation, and contingency planning for potential risks and challenges.

•     It shall outline procedures for monitoring and addressing risks throughout the project lifecycle.

 Communication and Reporting

•     The project plan shall define communication channels, frequency of communication, and reporting mechanisms for project updates, progress tracking, and issue resolution.

•     It shall identify key stakeholders and their respective roles in project communication and decision-making processes.

   Change Management

•     The project plan shall include a change management process to address scope changes, requirements modifications, and any deviations from the original project plan.

•     It shall outline procedures for documenting, assessing, and implementing changes while minimizing disruption to project timelines and objectives.

 Submission Requirement

•     The Vendor shall submit the detailed project plan as part of the technical proposal, providing sufficient detail and clarity to demonstrate the feasibility and viability of the proposed solution.

•     The project plan shall be reviewed and evaluated by the evaluation committee to ensure alignment with project objectives, requirements, and timelines.

 

 

    1. Suggested Hardware Requirements for Server

 

Minimum Hardware Specifications for WMS Server (the following are ONLY for guideline purposes, yet the vendor is bound to follow their own proposed solution sizing and technical specifications)

•     Processor: Intel Xeon E5 or higher (minimum 6 cores) or AMD equivalent.

•     Memory (RAM): 32 GB or higher, expandable based on needed volume.

•     Storage:

o     1 TB SSD for the primary storage (for system files and active workflows).

o     4 TB HDD for archival and document storage.

o     Redundant Array of Independent Disks (RAID) configuration for data redundancy.

•     Network: Dual Gigabit Network Interface Cards (NIC) for high-speed communication and redundancy.

•     Backup: NAS (Network Attached Storage) with automated backup schedules.

•     Power Supply: Redundant power supplies (UPS-backed).

 

Operating System

•     OS: Linux (latest) or Latest Microsoft Windows Server (preferred) – Licenses must be provided by the vendor.

•     Database: MySQL, PostgreSQL, or MS SQL for data storage and management. - Separate Licenses, hence needed, must be provided by the vendor.

•     Web Server: Apache or IIS depending on OS.

 

    1. Staging Environment

Provide an on premise (at CIB) staging environment for ensuring the seamless deployment and quality assurance of the WMS before it goes live. The staging environment will serve as a replica of the production environment where the steering committee can thoroughly test and validate new features, updates, and configurations in a controlled setting. The staging environment shall be installed at the provided by the vendor Hardware. We expect this action to be well reflected in the Project plan thus allowing the steering committee to assess the solution customization progress. No Separate server will be dedicated for this task, the suggested by the Vendor server Hardware and software should host this environment.

 

 

    1. Governance

A project steering committee, comprising representatives from relevant departments and stakeholders, will oversee the project's progress and provide guidance thus regular progress updates and reports will be presented to the steering committee for review and decision-making. Successful Vendor will be required to submit bi-monthly reports on development advancement and make sure the staging environment is always up to date with the latest phases releases.

 

    1. In Scope

     The following are considered in scope of this TOR and are required as an integral part of its implementation:

    • Procure and install at CIB premises the necessary hardware and software needed for the proposed Workflow Management System.
    • Any labor required and that is in favor of properly installing the needed solution hardware or software.
    • Any cabling and/or electrical work needed to properly install the solution hardware and software.
    • Configure the hardware and its needed software as per the solution requirements.
    • Work with CIB Team on integrating the solution within The CIB IT Infrastructure as per CIB IT Manager instructions and advice.
    • Train CIB IT Team on the proposed Hardware and software maintenance. Selected personnel shall be advised on by the CIB IT Manager.
    • Ensure, in close collaboration with CIB IT Manager, the secure exposure of the current solution Open API and Webbooks to the Internet for later CIB Website integration actions.
    • Onsite (no remote) Training sessions for the CIB IT and General staff on the solution features and usage. The sessions should be divided into:
      • Users Training
      • Server(s) IT administration
      • Solution administration including creating new workflows.

 

    1. Out of Scope

The following are considered out of scope of this TOR and are not required:

    • Any Hardware or software that are outside the proposed solution scope.
    • Providing Real IP or hosting services for the proposed solution.

 

    1. Vendor Compliance

The Vendor must provide a detailed Compliance Statement as part of their proposal, explicitly confirming adherence to all system requirements outlined in this Terms of Reference (TOR). The Compliance Statement should clearly address the following:

 

  • Functional Requirements: A confirmation that the proposed system meets or exceeds all functional requirements described in this TOR, including any specific workflow and integration requirements.

 

  • Non-Functional Requirements: Assurance that the system complies with all non-functional requirements, such as performance, scalability, security, usability, reliability, and maintainability, as specified.

 

  • Customization & Configuration: A statement confirming that any necessary customizations, configurations, or adjustments will be made to ensure full compliance with the operational needs of the organization as outlined.

 

  • Security & Data Protection: An explicit confirmation that the system adheres to security and data protection standards, including compliance with encryption, authentication, and audit logging requirements.

 

  • Testing & Validation: The Vendor must confirm that all system requirements will be thoroughly tested and validated before delivery and deployment, ensuring full compliance.

 

The Vendor must include a compliance checklist indicating each requirement and the corresponding confirmation of compliance, noting any exceptions or deviations with clear justifications and proposed alternatives.

 

Failure to provide a comprehensive Compliance Statement, or non-adherence to the requirements specified in this TOR, may result in disqualification from the selection process.

 

    1. Service Level Support

The vendor shall describe the support procedures that are to be during & followed the end of the Warranty period, according to the below table summarizing the levels of severity and corresponding Response/Resolution times

 

Level of urgency & specification

Response time

Priority A

Failure of software and hardware that causes service interruption

within 4-6 hours

Priority B

Error or problem that has caused loss of some functionality and/or may lead to service interruption

Within 1-2 Business days

 

Priority C

Problem during live operation that is clearly due to faulty behaviour; problem that shall have a long-term effect on production, although it shall not lead to immediate service failure

Less than 2-3 Business days

Priority D

Technical Queries from the Customer not related to a System fault and not affecting the operation and functionality of the system

Within 5 business days

Call Type
Call for Tenders
Organisation
Intervention Sectors
Training & Capacity Building
How to Apply

Interested applicants may apply online through the following link: https://www.marches-publics.gouv.fr/?page=Entreprise.EntrepriseDetailConsultation&id=2792768&orgAcronyme=s2d 

 

Deadline
Countries
Lebanon