Manual de Funcionament del Sistema – Manteniment

Versió: 1.0

Data de creació: 2025/12/07

Creat per: Alexis Daniel Pérez

PDF Original

Data de modificació: 2025/12/09

Modificat per: Alexey Martínez Meca

  1. Objectiu del Manual

    Aquest manual descriu com mantenir la fulla de càlcul en condicions òptimes perquè les dades reflecteixin la realitat operativa. Això implica garantir l’exactitud de préstecs, avaries, garanties i estats; prevenir errors que puguin alterar el dashboard; i establir procediments sòlids perquè qualsevol modificació quedi degudament registrada i controlada. En resum, el document serveix tant per a l'operativa diària com per a auditories i presa de decisions.

      Objectius concrets

    1. Mantenir integritat i coherència de dades.
    2. Minimitzar errors humans mitjançant normes i controls.
    3. Assegurar disponibilitat de la informació per a informes i dashboard.

  2. Àmbit d’aplicació

    Aquest manual s’aplica a totes les persones que interactuen amb la fulla: administradors de l’inventari, personal tècnic, responsables de préstecs i qualsevol usuari autoritzat per editar l’Excel. També és la referència per a consultors o auditors que necessitin entendre la lògica del fitxer.

  3. Estructura de la Fulla de Càlcul

    La fulla conté camps que han de mantenir-se coherents:

    1. ID Equip
    2. Tipus
    3. Marca
    4. Model
    5. Estat
    6. Usuari Actual
    7. Data Préstec
    8. Data Retorn Prevista
    9. Número d’Avaries
    10. Any d’adquisició
    11. Mesos de garantia
    12. Dies d’endarreriment

    La correcta definició i format d’aquests camps és la base perquè el dashboard i les fórmules funcionin sense errors.

      Nota:

    1. ID Equip: identificador únic i immutable.
    2. Estat: nomenclatura exacta (evitar variants tipogràfiques).
    3. Dates: format uniforme (DD/MM/AAAA) per evitar càlculs erronis.

  4. Normes Generals de Manteniment

    Per assegurar la integritat i la coherència de les dades, es seguiran les següents normes:

    1. Regles d’edició

      2. Les regles d’edició estableixen els criteris que s’han de seguir per modificar la fulla de càlcul sense comprometre la integritat de les dades ni el funcionament del dashboard associat. Tenen com a objectiu evitar errors, mantenir la coherència entre registres i garantir que totes les modificacions siguin traçables.

      En primer lloc, no es poden modificar columnes estructurals ni columnes que continguin fórmules o automatismes, ja que això podria generar errors de càlcul o desconfiguració del document. Qualsevol canvi d’estructura s’ha de comunicar prèviament i només pot ser executat pel responsable de l’inventari. De la mateixa manera, no s’han d’eliminar files encara que un equip sigui retirat o ja no s’utilitzi. En aquest cas, el procediment correcte és marcar-lo com FORA_SERVEI, aconseguint així que el dashboard segueixi mostrant els valors totals correctament.

      També cal evitar duplicar ID d’equip, ja que cada dispositiu ha de ser únic dins la base de dades. Si es detecta una duplicació accidental, el responsable ha de corregir immediatament una de les entrades. Finalment, es recomana no deixar buits els camps essencials com Estat, ID, Tipus o Usuari Actual quan hi hagi un préstec actiu, perquè aquests camps alimenten càlculs automatitzats.

    2. Nomenclatura

      3. La nomenclatura és un element fonamental per assegurar uniformitat i facilitar el filtratge, la cerca i els processos automàtics. Tot el material ha de seguir un sistema d’identificació coherent i estable, basat en un prefix i un número seqüencial (per exemple: ACC001, ACC002, EQP010). El format no s’ha d’alterar: sempre tres lletres seguides de tres dígits, sense espais ni caràcters especials.

      Pel que fa als estats, és imprescindible que s’escriguin sempre de la mateixa manera i que coincideixin exactament amb la llista establerta: DISPONIBLE, EN PRÉSTEC, FORA_SERVEI, EN REPARACIÓ, etc. Variants com “disponible”, “En prestec” o “fora servei” poden provocar errors al dashboard o a les fórmules condicionals.

      A més, els camps de text com Tipus, Marca o Model s’han de mantenir coherents, evitant abreviacions inconsistents (per exemple, alternar “HP” i “H.P.”). Aquest control garanteix una classificació clara i evita problemes en les cerques i informes.

    3. Controls de dates

      4. Els controls de dates tenen un paper essencial, ja que determinen el funcionament de càlculs automatitzats com els dies d’endarreriment, les revisions de garantia o els períodes de préstec. Per aquest motiu, totes les dates del document han de seguir un únic format: DD/MM/AAAA. No s’accepten variacions com “24-4-25”, “abril 2025” o expressions com “avui”, “demà” o “propera setmana”. Aquestes formes impossibiliten el càlcul automàtic i poden generar errors en el dashboard.

      És important que la Data de Préstec es registri sempre el mateix dia que es lliura el material, mentre que la Data de Retorn Prevista ha de seguir la política interna establerta (p. ex., 14 o 30 dies). A més, cada vegada que un equip es retorna, s’ha de garantir que la data real de retorn es registra correctament, ja que és la base per calcular si hi ha retard i per activar els corresponents indicadors visuals.

      Finalment, els controls de dates també afecten la gestió de garanties: és necessari que les dates d’adquisició i la durada de la garantia estiguin ben introduïdes, ja que qualsevol error podria fer que un equip aparegui com fora de garantia o dins de garantia incorrectament. Per això, es recomana revisar les dates periòdicament i utilitzar validacions que evitin formats incorrectes.

  5. Procediment d’Actualització de la Fulla

    L’actualització segueix procediments concrets segons l’operació: préstec, retorn, avaria o baixa.

    1. Quan hi ha un préstec

      2. Al registrar un préstec cal actualitzar l’Usuari Actual amb el codi d’usuari, la Data Préstec amb la data real d’entrega, la Data Retorn Prevista segons la política i l’Estat. S’actualitzarà el càlcul de dies d’endarreriment a posteriori.

    2. Quan es retorna un equip

      3. En el retorn, l’Estat canvia a DISPONIBLE, l’Usuari Actual queda buit i els camps de préstec poden esborrar-se o quedar com a historial segons la política.

    3. Quan hi ha una avaria

      4. S’ha d’incrementar el camp Número d’Avaries (+1), descriure l’incident a Observacions, posar l’Estat a EN REPARACIÓ o FORA_SERVEI i indicar si la garantia és vigent per decidir el procediment de reparació.

    4. Quan es dona de baixa un equip

      5. Marcar l’Estat com FORA_SERVEI, afegir una anotació explicativa a Observacions i no eliminar la fila perquè serveix d’històric i alimenta el dashboard.

  6. Procediment de Revisió Periòdica

    El procediment de revisió periòdica és essencial per garantir que la informació de la fulla d’inventari es manté actualitzada, coherent i lliure d’errors. Aquestes revisions tenen l’objectiu de detectar incoherències, identificar materials que requereixen intervenció i assegurar que totes les dades utilitzades pel dashboard i pels informes siguin correctes i fiables. La freqüència pot ser setmanal o mensual.

    1. Revisió de coherencia

      2. La revisió de coherència consisteix a verificar que totes les dades introduïdes segueixen el format establert i que no hi ha camps que mostrin informació contradictòria. Durant aquesta fase es comprova que no existeixin valors fora de llistes predefinides, que els ID no estiguin duplicats i que les columnes essencials no continguin buits que puguin afectar fórmules o informes posteriors. Aquest control garanteix que l’estructura de la base de dades es mantingui estable i funcional.

    2. Revisió de dates

      3. La revisió de dates té un paper crític, ja que aquestes influeixen en càlculs com els dies d’endarreriment, la vigència de les garanties o la planificació de pròxims retorns. En aquest control s’analitza si hi ha préstecs amb dates de retorn ja superades, si existeixen discrepàncies entre la data real i la prevista i si hi ha equips amb garanties pròximes a caducar. Qualsevol data inconsistent pot provocar errors en el dashboard o en la traçabilitat del material.

    3. Revisió d’estats

      4. Aquest pas assegura que l’estat assignat a cada material reflecteix fidelment la seva situació real. Es comprova que no hi hagi equips en EN PRÉSTEC sense data associada, materials en EN REPARACIÓ que porten massa temps pendents o dispositius marcats com FORA_SERVEI sense una justificació clara a les observacions. Aquest control ajuda a identificar omissions i materials que podrien estar bloquejant la disponibilitat general.

    4. Revisió del nombre d’avaries

      5. La revisió del nombre d’avaries permet detectar equips que presenten un historial de fallades superior al normal. Aquesta informació és essencial per prendre decisions sobre substitucions, renovacions o millores del manteniment preventiu. També facilita la detecció d’usos inadequats o de punts febles associats a determinats models o marques.

  7. Gestió de Còpies de Seguretat

    La gestió de còpies de seguretat assegura que sempre es disposi d’una versió recuperable del document en cas d’error, corrupció o modificació incorrecta. Aquest procés és imprescindible quan el fitxer conté fórmules complexes o quan depèn del dashboard per a informes corporatius.

    1. Freqüència

      2. És recomanable realitzar una còpia de seguretat de manera setmanal, especialment en entorns amb alta rotació de préstecs o incidències. A més, s’ha de crear una còpia abans de qualsevol actualització massiva o modificació tècnica que pugui afectar estructures o fórmules.

    2. Localització

      3. Les còpies de seguretat han d’emmagatzemar-se en una ubicació segura, preferiblement en una carpeta compartida amb control d’accés i amb versions numerades per facilitar la traçabilitat (Ex: Inventari_v3.2). Aquesta organització permet recuperar ràpidament versions prèvies si fos necessari.

    3. Recuperació

      4. En cas d’error o corrupció del document principal, s’ha de seguir un protocol de recuperació: identificar la versió funcional més recent, substituir el fitxer principal i comunicar la incidència als responsables. Aquest procediment garanteix la continuïtat de les operacions i evita interrupcions en la gestió del material.

  8. Controls de Qualitat Final

    Els controls de qualitat final es realitzen habitualment de manera mensual i tenen com a objectiu verificar que totes les dades del sistema són coherents i fiables. Durant aquesta revisió s’analitza si el nombre total d’equips coincideix amb el registre físic, si les columnes obligatòries estan correctament emplenades i si el dashboard reflecteix valors consistents. També es revisen formats, es detecten errors de duplicació i s’eliminen elements sobrants que puguin afectar la llegibilitat o el rendiment del document. Aquest conjunt de controls permet mantenir un sistema d’inventari robust, professional i lliure d’incidències.