• Phase 4: Production Support & Maintenance

    User support & on-going maintenance.

    broken image

  • Primero Support Hub

     

    The Primero Support Hub is our central repository of all release documentation, knowledge base articles, user guides and general support. Here we maintain a well-curated knowledge base made up of well-documented resolutions, best-practices, video tutorials to disseminate knowledge to end users and administrators.

     

    You can also find details of upcoming feature development in our roadmap.

     

    Visit the Primero Support Hub at https://support.primero.org.

     

    Primero Support Hub Objectives

    Cost effective central support for CPIMS+ developers, coordinators, administrators and users

    • Using the Primero Support Hub can help CPIMS+ level 1 support teams resolve issues more efficiently, with the goal being to reduce escalations
    • Providing access to comprehensive user and developer guides and documentation
    • Announcements of Primero news, releases, release notes and roadmap 
    • Proactive discussion board and FAQ
    • Helpdesk and ticketing system for system issues, easily assigned to vendors for review and action
    • Central repository of feature enhancements
    • All users can utilize the discussion board to help troubleshoot issues

    User and Technical Support

    It is critical that all help requests are appropriately logged and that requests from the different implementation sites are consolidated into a central register for knowledge sharing and sustainable support. We use the Support Hub as that register.

     

    First it is worth understanding the levels of support. User and technical support for the application has been broken up into three categories: Level 1, Level 2, Level 3. The levels correspond to ascending difficulty in finding a solution to a problem:

     

    Level 1: A user support problem that can be resolved either by training, guidance, or by a system administrator making a small change in the application. Examples are:

    • Password lost or reset request
    • User Error issues
    • Any “How to” and “Why can’t I” questions which cannot be resolved using existing documentation or training materials

    Level 2: An issue that can be resolved by a coordinator or a support staff who has undergone System Administrator training and with a deeper understanding of the system.

     

    Level 3: An issue which requires technological assistance from developers. Issues requiring level 3 support are those that affect work and require an immediate code change and rollout to production (a “hotfix”), or an immediate upgrade to an operating system component.

    The process will begin with Level 1 support, and will “escalate” up to Level 2 only when the issue/request cannot be addressed by Level 1 support providers. If the issue/request cannot be addressed by Level 2 support, it will be escalated to Level 3. Please follow the guidance on support and the escalation process. 

     

    Service-Level Agreement (SLA)

    • This is the “contract” we have with software vendors wherein we define the specific expectations and processes for providing support.
    • Example: For a Level 3 issue, response X, Y, Z in 72 hours.

    ​

    Firecall Access
    • What is Firecall Access? Firecall is emergency access to a secure information systems in the event of critical errors to correct the system.
    • A support user logging in to the server backend has unrestricted access to the system. To mitigate risks, it is recommended to audit and selectively grant system access for support. The procedures and technology that guides this support access is known as “Firecall”.
    • In order to provide Level 2 and level 3 support, external IT staff will be required to gain access to the server and data. A written request by the system administrator must initiate the sequence that allows external parties to log into the server. The CPIMS+/CPIMS+ System Administrator will be responsible for logging these requests to provide an audit trail of system level access.
    • System access is enforced through SSH keys. It is recommended to allow only designated users with designated SSH keys access to the server. For the Beta release, keys belonging to known support staff and selected through the CPIMS+ Global Support team will be present on the server.
    • A request to access can include a public key which is added by the CPIMS+ System Administrator, and then removed at the end of the support procedure. This approach ensures that the CPIMS+ System Administrator will have the final ownership and responsibility over the system.
    • Aside from this guidance, no tool currently exists to reliably audit and restrict access to UNICEF CPIMS+ machines.
    Maintenance Releases & Notifications
    • Software application updates will be made by the IT support team in coordination with the CPIMS+ System Administrator. They will require no action on the part of the end users, although the System Administrator must schedule and communicate an appropriate time with the end users when the system will not be available.
    • There is ongoing development and bug fixing in CPIMS+. Some features and fixes may be of interest to the country implementation team and System Administrator and some may not. The development team will attempt to conservatively balance the release between desired functionality, bug fixes, security, and potential risk to system stability when introducing upgrades.
    • The following may be released during maintenance:
      1. Requested features.
      2. Complex configuration changes made in coordination with the national CPIMS Coordinator and the System Administrator
      3. Bug fixes either identified by the CPIMS+ development team or by users in country.
      4. Security updates.
    • The maintenance release will be periodic and scheduled well ahead of time to avoid any disruptions.
    • If needed, the Primero mobile application will be updated via the MAM tool suite. This software release will again be managed by the UNICEF Country ICT team and coordinated with the CPIMS+ server release.
    • Users will be notified via the system administrator and software development vendor on all maintenance releases
    • When hosting using UNICEF's Microsoft Azure Cloud Services, server performance and monitoring is a part of the cloud services and allow additional levels of data protection
    Decommissioning / Sunsetting
    • If the mission of the CPIMS+ case management application has been fulfilled, or the product has been superseded, or is no longer sustainable, it needs to be decommissioned.
    • The following should be considerations for a decommission plan:
    1. Ownership, confidentiality, and potential destruction of the data currently stored in CPIMS+
    2. Migrating data and user base to new product, if applicable
    3. Shutting down or repurposing the existing hardware and cloud services
    4. Programmatic changes
    • More details on putting together a plan for decommissioning a UNICEF ICT product can be found here.
    Finally, don't forget!
    • Ensure you have forecasted the on-going budget and sustainability of CPIMS+
    • Continue to invest in capacity building on both case management and CPIMS+ as needed
    • Set up a long term strategic roadmap to scale up
All Posts
×
Cookie Use
We use cookies to ensure a smooth browsing experience. By continuing we assume you accept the use of cookies.
Learn More