Ame em-asset verification-highlevel proposal-v3

3
PAGE 8 OF 16 Asset Verification Project Proposed High Level Solution Proposed (High-Level) Asset Verification Workflow The following diagram provides a suggested highlevel workflow for the Asset Verification functions: CI Record SCCM Data Primary User Used By User Last Scan Date Last Verification Date Verification Status BMC Service Request Asset Verification SRD 2 Update Used By 3 Update Scan Data 8 Compare User Data 9 Verificaiton Notificaiton 10 Verificaiton Response Verificaiton Update Asset Analyst EMIT Asset Mgt Team List of Assets that require user validation 7 Submit Asset List BMC Analytics Asset Verification Report Data 4 Collate Asset Data 6 Exception Reports End User (Custodian) Mismatched User Report Last Scan Data Report Primary User Report Used By Report Last Verification Report BMC Atrium Console Verification Job Verificaiton Job 1 5 Compare Fixed A List 11 Figure 1. Proposed HighLevel Asset Verification Workflow The following steps are required to facilitate the asset verification workflow: 1. Verification Job – This is a preconfigured automated job designed to execute against the Production Dataset (BMC.Asset) to determine the asset/CI that comply with verification status based on a list of qualifying criteria. At the conclusion of the job run each asset/CI will be updated with one of the following statuses: a. Validated – via Job b. UnValidated – No Primary User (Blank)

Transcript of Ame em-asset verification-highlevel proposal-v3

Page 1: Ame em-asset verification-highlevel proposal-v3

PAGE 8 OF 16

Asset Verification Project Proposed High Level Solution

Proposed (High-Level) Asset Verification Workflow

The following diagram provides a suggested high‐level workflow for the Asset Verification functions: 

CI Record

SCCM Data

Primary User

Used ByUser

Last Scan Date

LastVerification

Date

Verification Status

BMCService Request

Asset Verification SRD

2UpdateUsed By

3

UpdateScan Data

8

CompareUser Data

9

VerificaitonNotificaiton

10VerificaitonResponse

VerificaitonUpdate

Asset Analyst

EMITAsset Mgt Team

List of Assets that require user validation

7

SubmitAsset List

BMCAnalytics

Asset Verification Report Data

4

CollateAsset Data

6

ExceptionReports

End User(Custodian)

Mis‐matched User ReportLast Scan Data ReportPrimary User ReportUsed By ReportLast Verification Report

BMCAtrium Console

Verification Job

VerificaitonJob

1

5

CompareFixed A List

11

Figure 1. Proposed High‐Level Asset Verification Workflow            

The following steps are required to facilitate the asset verification workflow: 

1. Verification Job  –  This  is  a  pre‐configured  automated  job  designed  to  execute  against  the  Production  Dataset 

(BMC.Asset) to determine the asset/CI that comply with verification status based on a list of qualifying criteria. At the 

conclusion of the job run each asset/CI will be updated with one of the following statuses:  

a. Validated – via Job 

b. UnValidated – No Primary User (Blank) 

Page 2: Ame em-asset verification-highlevel proposal-v3

PAGE 9 OF 16

Asset Verification Project Proposed High Level Solution

c. UnValidated – No Used By User (Blank) 

d. UnValidated – User Mismatch 

e. Unvalidated – Currently In Inventory 

f. Unvalidated – Last Scan Date Expired 

 

2. Update “Used by” relationship – at some point during the asset maintenance process the “Used by” information would 

have been updated to reflect the current custodian (used by user).  

3. Update “Scan Data” – Microsoft SCCM will provide “Primary User” and “Last Scan Date” and update CI record  for a 

particular asset.  

4. Collate Asset Data – Verification Status, Verification Dates, Used by, Primary User and Last Scan date fields will be made 

available to BMC Analytics to allow Fixed Asset Analyst/Auditors to determine next set of asset/CIs to perform end user 

verification analysis. 

5. Compare Fixed Asset List – Asset Analyst will compare the list of assets to be audited against the asset/CI verification 

status. A series of exception reports will be created based on Analytics data. 

6.  Exception Reports – Asset Analyst will generate reports from Analytics. Sample list of reports: 

a. Mis‐matched “Primary” User vs “Used by” User Report 

b. Last Scan Data exceeds > 45 days Report 

c. Primary User = “blank” Report 

d. Used By = “blank” Report 

e. Last Verification exceeds > 90 days Report 

7. Submit Asset List – Asset Analyst will submit a list of serial numbers that require end user verification. This list would be 

entered directly into the SRM – Asset Verification SRD.  

8. Compare User Data – The SRM – Asset Verification would retrieve the “Primary User” and the “Used by User” for the 

defined list of assets (via serial number). A comparison would be facilitated between the two values. If the values do NOT 

match  then proceed  to  the next step.  If  the  two values  for  the same asset matches,  then  there  is no  further action 

required. 

9. Verification Notification – A notification email will be sent to the defined “Primary User” to solicit a validation whether 

they are the actual custodian for the asset/CI. A formatted email template will be used to collect information from the 

end user. 

10. Verification Response – The notified user will be required to respond within 10 business days to either confirm or deny 

custodianship of the designated asset/CI.  

Page 3: Ame em-asset verification-highlevel proposal-v3

PAGE 10 OF 16

Asset Verification Project Proposed High Level Solution

11. Verification Update – After confirmation has been received that custodian (used by) should be updated, the CI record 

for the associated asset/CI will be updated with the appropriate “Used by” user, verification status as “Validated – via 

Custodian” and a last verification date.