Fermer

septembre 29, 2020

Sauver le cas et votre santé mentale dans Argus Safety


Vous êtes-vous déjà demandé pourquoi les fonctionnalités d'Argus Safety que vous utilisez depuis des mois ou des années ont soudainement commencé à se comporter comme si quelqu'un avait secrètement changé votre configuration? Tout le monde, à un moment donné, a l'impression que son système est devenu son propre jumeau maléfique.

Explorons quelques raisons courantes pour lesquelles Argus Safety commence, sans avertissement, à se comporter mal:

  1. Data Migration : This est un scénario trop courant où les données d'un système hérité ou d'une acquisition sont migrées dans votre monde Argus parfait. La cause la plus courante est que les données que vous avez migrées depuis l'ancien système ne sont pas correctement mappées à leur espace légitime dans Argus, et maintenant, elles ne se comporteront pas comme prévu. La plupart des occurrences après la migration des données peuvent être évitées grâce à un plan de migration robuste, une configuration système correcte et des tests précoces pour garantir que les données migrées n'ont pas d'effets en aval imprévus. Méfiez-vous des données qui ont été migrées plusieurs fois!
  2. Changements de configuration du système: Nous voulons tous la configuration parfaite pour maximiser l'utilité de notre système. Passer maintenant à l'utilisation des technologies AI, ML, NLP et RPA, parfois configurer la configuration sans réfléchir aux scénarios de la façon dont les données répondront à vos changements les mieux intentionnés peut créer un désordre. Par exemple, Harold souhaite nettoyer l'ancienne configuration du site et s'assurer que tous les processeurs de cas peuvent afficher tous les cas. Le simple fait de désactiver ces configurations de site indésirables et de placer tous les utilisateurs dans un seul compartiment a des ramifications au niveau du cas. Très probablement, ces problèmes n'apparaîtront qu'à un moment critique et prendront des heures à être résolus. C'est une bonne pratique d'avoir quelqu'un dans votre groupe qui connaît la vraie fonctionnalité et la logique d'Argus à demander avant de ranger.
  3. Problèmes non techniques: Ne pas enlever les mystères fantastiques de la technologie, rappelez-vous que vous êtes travailler avec un progiciel avec sa propre logique codée en dur. Nous les humains (du moins la plupart d'entre nous) ne sommes pas codés en dur dans notre façon de penser et de traiter. Le logiciel doit être dans une certaine mesure. La cause la plus importante des données bancales? Ne pas avoir les bons conseils de traitement des cas pour prendre en charge la configuration de votre système. Cela inclut ce que vous pouvez et ne pouvez pas faire dans le système. Mettre en place des directives de traitement des cas en fonction de la configuration de votre Argus Safety semble être un point de départ logique, mais nous manquons souvent les chevaux à la recherche de zèbres. Lorsque les données commencent à prendre une tournure inattendue ou que la fonctionnalité attendue commence à ne pas fonctionner, il est temps de creuser et de rechercher la cause. Regardez vos directives de traitement de cas ou vos conventions de codage. Une orientation bien pensée; surtout si vous sous-traitez, est essentielle au succès et à l'efficacité du traitement de votre dossier. Cela réduit également le nombre de comportements aberrants.

Voici quelques éléments qui compliquent le traitement des cas ou les instructions de travail; conduit au stress, à la frustration et à la non-conformité:

  1. Plusieurs conseils intégrés dans un seul document: Le guide de traitement dans le pire des cas ne tient pas compte de la base de données de sécurité Argus et contient de nombreuses références intégrées dans le document obligeant l'utilisateur à cliquer plusieurs fois pour trouver la bonne réponse. Plutôt que d'incorporer un document dans un document, communiquez d'avance les informations disponibles avec les captures d'écran Argus Safety correspondantes. Divisez-le en zones logiques de votre flux de travail, c'est-à-dire une section sur «Traitement des cas AE graves», sans oublier le processus mais les délais.
  2. Traitement de code obsolète ou instructions de codage d'examen médical: Après toute modification apportée à la base de données Argus Safety, les documents de traitement des dossiers doivent être revus et mis à jour. Rien n'est plus frustrant que d'arriver à un nouvel écran dans Argus (c'est-à-dire après l'application des correctifs), et l'utilisateur ne sait pas quoi faire avec les champs de données. Les versions prises en charge d'Argus Safety sont conçues pour être suffisamment flexibles pour s'adapter aux changements réglementaires. Cela se fait généralement en appliquant un correctif au système sous vos procédures et tests SDLC.

Maintenant… aux informations sur l'importance de sauvegarder un cas dans Argus!

 Image 1

Parlons d'un scénario spécifique de ce qui ne peut pas être fait dans Argus lors de la planification manuelle d'un rapport accéléré.

Vous avez planifié un rapport accéléré; il s’agit d’un cas de courte durée et doit être soumis maintenant. Vous avez remarqué que vous avez choisi la mauvaise licence de produit lors de la planification. Le bon sens vous le dit (sans consulter votre document d'orientation pour supprimer le rapport et en programmer un nouveau.

 Image 2

Après avoir planifié un nouveau rapport avec des paramètres corrects, le rapport planifié affiche un rapport incorrect numéro de version. Le rapport est censé être le suivi n ° 1, mais il affiche le suivi n ° 2 dans l'onglet Rapports réglementaires.

 Image 3

Cela n'a aucun sens en regardant l'écran. La logique humaine dit de le réparer. Vous supprimez le rapport et en programmez un nouveau en espérant qu'il affichera la bonne version.

 Image 4

À votre grande surprise, il n'a pas été corrigé le problème. Il planifie toujours le suivi n ° 2 au lieu du suivi n ° 1.

 Image 5

Qu'est-ce que c'est?

Argus Safety attend des mesures concrètes, ce que nous oublions parfois. Par exemple, vous avez oublié de cliquer sur le bouton "ENREGISTRER" après avoir marqué le rapport F / up # 1 pour suppression au début. dans un nouveau rapport de suivi n ° 2 au lieu du rapport de suivi n ° 1.

Regardez ci-dessous pendant que vous êtes frustré et que vous essayez de planifier de manière urgente un rapport accéléré, notez que l'interface utilisateur d'Argus Safety n'a pas supprimé l'entrée de rapport supprimée [19659023] jusqu'à ce que vous enregistriez le cas . C'est la raison pour laquelle même la reprogrammation du rapport ne corrige pas la version du rapport dans ce scénario.

 Image 6

Bien que la sortie du rapport généré imprime le numéro de suivi correct (si applicable pour le type de formulaire de rapport) mais le numéro de version du rapport sur l'interface utilisateur est déroutant et rend le suivi de ce cas difficile à l'avenir.

Que pouvez-vous faire pour éviter ces types d'idiosyncrasies Argus?

Voici où un examen approfondi des étapes de traitement des cas par rapport à vos actions avant de passer à l'étape suivante peut vous faire gagner du temps et gagner de la frustration. Sinon, il devient difficile de résoudre ces types de problèmes subtils. Si vous n’avez pas détecté cette erreur et soumis les cas avec un numéro de version incorrect, cela coûtera plus tard dans le cas de la vie. Bien qu'il soit techniquement possible de corriger, ce n'est pas un travail amusant de corriger les versions de cas, car les consignes de traitement des demandes ne spécifiaient pas les détails ou vous ne les regardiez pas. D'où l'attention ci-dessus aux lignes directrices de cas utiles.

Nous voulons tous être très performants, mais les étapes logiques dictent le succès:

N'oubliez pas de sauvegarder le cas avant / après l'exécution des étapes cruciales comme la saisie de données, la planification de rapports , la suppression du rapport, etc. Cela garantira que la prochaine étape de traitement des cas sera effectuée sur les données les plus à jour et non sur les données à moitié traitées, comme vous l'avez remarqué dans l'exemple ci-dessus. situations embarrassantes, leur temps et leur argent sont dépensés pour comprendre et résoudre ces problèmes. Nous vous recommandons donc d'avoir:

  • Des instructions de travail complètes pour capturer les détails, y compris des étapes petites mais essentielles telles que la sauvegarde d'un cas. Pour ceux qui se noient dans les détails, s'il est important de le rappeler:
  • Des précautions telles que «N'OUBLIEZ PAS DE SAUVEGARDER LE CAS APRÈS LA SUPPRESSION DU RAPPORT» aux étapes sujettes aux erreurs
  • Listes de contrôle des onglets dans Argus identifiant le cas critique étapes de traitement basées sur votre configuration Argus Safety
  • Guides de l'utilisateur détaillés conçus pour des rôles spécifiques et alignés sur vos processus opérationnels PV

En fin de compte, la meilleure pratique consiste à examiner votre configuration Argus Safety par rapport à ce qui est pratique pour votre organisation, ce qui fonctionne bien par rapport à l'endroit où les erreurs courantes sont commises. Établir non seulement des directives de traitement des dossiers, mais aussi avoir une discussion précoce et réfléchie sur la configuration de votre système avant qu'il ne devienne incontrôlable est un must pour maintenir une équipe d'exploitation PV qui fonctionne correctement.

Un mot sur la configuration de sécurité Argus: L'interface utilisateur (UI) a été déplacée vers l'avant d'Argus, elle a permis aux utilisateurs d'exécuter des fonctions de base. Ces modifications du système sont capturées dans la piste d'audit et facilitent la documentation des modifications apportées à une base de données validée. Une organisation devrait éviter de désigner trop de rôles d'administrateur pour contrôler les modifications de configuration. Avant de modifier la configuration, examinez attentivement la fonctionnalité du système et les effets potentiels en aval. Effectuez des tests approfondis dans vos environnements inférieurs avant de l'implémenter dans votre système de production. Si vous n'êtes pas sûr de l'impact ou si vous avez besoin d'aide avec un «bilan de santé» de votre système de sécurité Argus, veuillez contacter l'équipe PV / Sécurité de Perficient.

À propos de l'auteur

Consultant en chef d'entreprise PV /Sécurité.

Mandeep est un spécialiste certifié de la mise en œuvre de la sécurité Oracle Argus avec une expérience en développement de suite de produits Argus Safety et a dirigé avec succès plusieurs projets Argus Safety pour des implémentations, des mises à niveau, des intégrations, des migrations et des optimisations de processus métier en tant qu'expert en la matière (PME), analyste commercial senior (BA ) et configuration lead pour de nombreuses sociétés pharmaceutiques.

Plus de cet auteur




Source link