Asset Lifecycle در AssetExplorer؛ از تخصیص تا Offboarding

شرکت مدانت

[ مجری تخصصی پیاده‌سازی چارچوب ITIL و تحول دیجیتال ]

کارمند جدید از دوشنبه شروع به کار می‌کند. واحد منابع انسانی می‌گوید لپ‌تاپ باید آماده باشد. انبار می‌گوید دستگاه موجود است. تیم IT یک سیستم را تحویل می‌دهد، اما بعد از چند ماه مشخص می‌شود Asset Tag ثبت نشده، Warranty رو به پایان است، دستگاه هنوز در سیستم به نام کارمند قبلی است و هنگام خروج همان کارمند نیز هیچ Workflow مشخصی برای تحویل گرفتن لپ‌تاپ وجود ندارد.

این سناریو فقط مشکل Inventory نیست؛ مشکل Asset Lifecycle Management است. داشتن فهرست دستگاه‌ها زمانی ارزش واقعی پیدا می‌کند که سازمان بداند هر دارایی از لحظه درخواست و خرید تا تخصیص، استفاده، تعمیر، انتقال، بازپس‌گیری و در نهایت Retirement یا Disposal چه مسیری را طی می‌کند.

Asset Lifecycle در AssetExplorer دقیقاً برای همین مسئله اهمیت دارد. ManageEngine AssetExplorer مدیریت دارایی را از یک لیست ایستا فراتر می‌برد و به سازمان کمک می‌کند وضعیت، مالک، محل، هزینه، قرارداد، Warranty و مرحله عمر هر Asset را در یک Repository مرکزی نگه دارد. در نسخه Cloud نیز Visual Workflow برای استانداردسازی فرآیندهایی مانند Asset Allocation و Asset Reclamation ارائه شده است.

Asset Lifecycle Management چیست؟

مدیریت چرخه عمر دارایی یعنی کنترل سیستماتیک یک Asset از قبل یا هنگام Procurement تا پایان استفاده و Disposal. در ITAM بالغ، Asset فقط «یک لپ‌تاپ با Serial Number» نیست؛ یک موجودیت مالی، عملیاتی، امنیتی و قراردادی است که در طول زمان Owner، Location، State، Cost و Risk آن تغییر می‌کند.

چرخه ساده یک لپ‌تاپ سازمانی می‌تواند چنین باشد:

Requested → Approved → Purchased → Received → In Stock → Assigned → In Use → Under Repair → In Use → Reclaimed → In Stock → Reassigned → Retired → Disposed

اگر سازمان فقط مرحله «In Use» را ثبت کند، بخش بزرگی از کنترل ITAM از دست می‌رود.

چرا Inventory به‌تنهایی کافی نیست؟

Inventory می‌گوید چه دارایی‌هایی دارید. Lifecycle Management می‌گوید هر دارایی الان در چه وضعیتی است، قبلاً دست چه کسی بوده، چه زمانی باید برگردد، چه قراردادی به آن وصل است و قدم بعدی چیست.

سؤال	Inventory ساده	Asset Lifecycle Management
چه Deviceهایی داریم؟	پاسخ می‌دهد	پاسخ می‌دهد
الان دست چه کسی است؟	گاهی	باید مشخص باشد
قبلاً دست چه کسی بوده؟	معمولاً محدود	History مهم است
Warranty چه زمانی تمام می‌شود؟	ممکن است ثبت شود	بخشی از Lifecycle است
در Offboarding چه اتفاقی می‌افتد؟	خارج از Scope	Reclamation باید تعریف شود
بعد از تعمیر به کجا برمی‌گردد؟	نامشخص	Transition تعریف می‌شود
چه زمانی باید Dispose شود؟	نامشخص	بر اساس Policy/Cost/Risk

AssetExplorer در چرخه عمر دارایی چه نقشی دارد؟

ManageEngine AssetExplorer یک راهکار IT Asset Management با CMDB یکپارچه است. در معرفی رسمی محصول، قابلیت‌هایی مانند Asset Inventory، Software Asset Management، License Compliance، Purchase Order و Contract Management، Remote Control و Asset Life Cycle Management ذکر شده‌اند.

بنابراین AssetExplorer می‌تواند چند لایه داده را کنار هم قرار دهد:

شناسه فیزیکی: Serial Number، Asset Tag، Barcode؛
شناسه فنی: IP، MAC، Hostname، Hardware/Software Inventory؛
مالکیت: User، Department، Site، Location؛
وضعیت: In Store، In Use، Under Repair، Disposed و Stateهای سفارشی؛
مالی: Purchase Cost، PO، Vendor، Depreciation و TCO؛
قراردادی: Warranty، Lease، Contract و تاریخ انقضا؛
ارتباطی: Relation با سایر CIها در CMDB.

مرحله اول: Procurement را به Asset Record متصل کنید

بسیاری از خطاهای ITAM قبل از ورود دستگاه به شبکه شروع می‌شوند. اگر Procurement جدا از Asset Management باشد، دستگاه خریداری می‌شود اما اطلاعات PO، Vendor، قیمت، Warranty و مالک هزینه به Asset نهایی متصل نمی‌شود.

AssetExplorer قابلیت Purchase Order Management دارد. در فرآیند مناسب، درخواست خرید باید حداقل این داده‌ها را تولید کند:

Vendor؛
Product/Model؛
Quantity؛
Unit Cost و Total Cost؛
PO Number؛
Expected Delivery؛
Cost Center؛
Department یا Project مقصد؛
Warranty/Support Information.

بعد از دریافت کالا، Asset نباید به‌صورت دستی و مستقل دوباره ساخته شود؛ باید تا حد ممکن با داده Purchase Reconcile شود تا Duplicate Asset ایجاد نشود.

Reconcile چرا در دریافت تجهیزات مهم است؟

یکی از مشکلات رایج این است که دارایی یک‌بار هنگام دریافت از PO ایجاد می‌شود و بار دوم وقتی Network Scan همان Device را کشف می‌کند. نتیجه: دو Record برای یک لپ‌تاپ.

در Release Notes رسمی AssetExplorer، قابلیت Reconcile برای تطبیق Assetهای ایجادشده از دریافت PO با Assetهایی که هنگام Scan اضافه شده‌اند وجود دارد. این فرآیند برای حفظ یک Source of Truth بسیار مهم است.

قاعده عملی این است که Serial Number، Service Tag، Asset Tag و سایر شناسه‌های پایدار در طراحی Reconciliation جدی گرفته شوند.

مرحله دوم: In Stock با «گم‌شدن در انبار» فرق دارد

دارایی In Stock باید همچنان Owner عملیاتی، Location و Status مشخص داشته باشد. اگر ۸۰ لپ‌تاپ در انبار دارید اما معلوم نیست در کدام شعبه، قفسه یا Warehouse هستند، سیستم فقط یک موجودی عددی دارد.

برای Assetهای Stock حداقل این موارد را نگه دارید:

Location/Site؛
Custodian یا مسئول انبار؛
Asset Tag/Barcode؛
Model و Specification؛
Warranty Expiry؛
Ready/Not Ready Status؛
Reservation برای Onboardingهای آینده.

مرحله سوم: تخصیص Asset در Onboarding

Onboarding موفق فقط ساخت User Account نیست. باید دارایی‌های لازم نیز به شخص درست تخصیص داده شوند. لپ‌تاپ، Monitor، Dock، Mobile Device، Token، Headset و سایر تجهیزات باید بخشی از Checklist شروع به کار باشند.

در معماری بهتر، درخواست Onboarding از HR یا ITSM باید به Allocation Asset منتهی شود. اگر می‌خواهید خود فرآیند Onboarding و Offboarding را از منظر ITSM ببینید، مقاله Onboarding و Offboarding کارکنان در پایگاه ServiceDesk مدانت مکمل این بحث است.

چه داده‌ای هنگام تحویل باید ثبت شود؟

Assigned User؛
Department؛
Location؛
Assignment Date؛
Expected Return Date در صورت Loan/Temporary Use؛
Condition هنگام تحویل؛
Accessoryهای همراه؛
Asset Acknowledgement یا سند تحویل در فرآیند سازمان.

هدف این است که بعداً سؤال «این لپ‌تاپ دست چه کسی است؟» بدون تماس و جست‌وجوی دستی پاسخ داده شود.

Asset State باید معنای عملیاتی داشته باشد

Stateهایی مثل In Use، In Store، Under Repair و Disposed فقط برچسب نیستند؛ هر کدام باید رفتار عملیاتی مشخصی داشته باشند.

State	معنای پیشنهادی	کنترل لازم
In Stock	دارایی آماده تخصیص است	Location و Custodian مشخص
Reserved	برای User/Project رزرو شده	Reservation Expiry
In Use	به User/Department تخصیص داده شده	Owner و Assignment Date
Under Repair	موقتاً خارج از سرویس است	Repair Vendor/Cost/ETA
Loaned	امانت کوتاه‌مدت	Return Date
Reclaimed	از کاربر پس گرفته شده	Inspection و Data Handling
Retired	دیگر برای Production استفاده نمی‌شود	Data Wipe/Disposition Decision
Disposed	از مالکیت عملیاتی خارج شده	Evidence و Financial Closure

نسخه Cloud؛ Visual Workflow برای Allocation و Reclamation

ManageEngine در نسخه Cloud AssetExplorer، Visual Workflow Builder را برای اتوماسیون چرخه عمر ارائه کرده است. طبق معرفی رسمی Cloud، فرآیندهایی مانند Asset Allocation و Asset Reclamation را می‌توان با Workflow بصری استاندارد کرد و در Stateهای مختلف Custom Action اجرا کرد.

این قابلیت برای سازمانی مفید است که نمی‌خواهد State Change فقط به تصمیم دستی یک کارشناس وابسته باشد.

یک Workflow نمونه می‌تواند چنین باشد:

Asset به کاربر Assign می‌شود.
State به In Use تغییر می‌کند.
Owner و Department Update می‌شوند.
Notification برای User یا Asset Manager ارسال می‌شود.
هنگام Offboarding، Reclamation Workflow شروع می‌شود.
پس از تحویل، State به Reclaimed تغییر می‌کند.
Inspection انجام می‌شود.
دستگاه به In Stock، Repair یا Retired می‌رود.

در On-Premises نیز Asset State و فرآیندهای Purchase/Contract/Inventory برای کنترل چرخه دارایی استفاده می‌شوند؛ اما قابلیت‌ها و مسیرهای Automation باید بر اساس Build واقعی محیط بررسی شوند.

Offboarding؛ نقطه‌ای که دارایی‌ها معمولاً گم می‌شوند

وقتی کارمند سازمان را ترک می‌کند، تیم Identity معمولاً Account را Disable می‌کند؛ اما Asset Reclamation گاهی به یک تماس تلفنی یا Excel سپرده می‌شود.

این شکاف می‌تواند باعث شود:

لپ‌تاپ پس گرفته نشود؛
Asset هنوز به User قبلی Assign بماند؛
SIM، Token یا Accessory فراموش شود؛
داده سازمانی روی Device باقی بماند؛
Device بدون Inspection به نفر بعدی داده شود؛
Inventory و CMDB از واقعیت فاصله بگیرند.

یک Checklist برای Asset Reclamation در Offboarding

تمام Assetهای Assigned به User را Query کنید.
Device، Monitor، Dock، Mobile، Token و Accessoryها را جداگانه کنترل کنید.
Return Date و Condition ثبت شود.
Data Backup در صورت نیاز انجام شود.
Data Wipe/Reset بر اساس Policy امنیتی اجرا شود.
Device از User قبلی Unassign شود.
Warranty و Hardware Health بررسی شود.
State به Reclaimed یا Under Inspection برود.
در صورت سلامت، Asset به Stock برگردد.
در صورت خرابی، Repair Workflow شروع شود.
در صورت End-of-Life، Retirement/Disposal آغاز شود.

Reassignment؛ Asset سالم را بی‌دلیل نخرید

یکی از اهداف مالی ITAM افزایش Utilization است. اگر Asset Reclamation درست باشد، سازمان قبل از خرید لپ‌تاپ جدید می‌تواند دارایی‌های قابل استفاده را از Stock یا Reclaimed Pool ببیند.

این موضوع ساده مستقیماً روی TCO اثر دارد. اما برای تصمیم درست باید بدانید:

سن دستگاه چقدر است؟
Warranty معتبر دارد؟
مشخصات برای Role جدید مناسب است؟
هزینه Repair چقدر بوده؟
Health دستگاه مناسب است؟
Data Wipe کامل شده؟

Asset Lifecycle خوب، خرید را از «اولین واکنش» به «آخرین گزینه بعد از بررسی موجودی قابل استفاده» تبدیل می‌کند.

Warranty را بخشی از Lifecycle ببینید

Warranty Expiry فقط یک فیلد اطلاعاتی نیست. اگر ۱۰۰ لپ‌تاپ در سه ماه آینده از Warranty خارج شوند، این اتفاق باید در Budget، Replacement Plan و Risk Register دیده شود.

در AssetExplorer اطلاعات Warranty و Contract قابل نگهداری هستند و Release Notes رسمی نیز قابلیت‌های مرتبط با Warranty، Contract و Notification را در نسخه‌های مختلف نشان می‌دهد.

یک برنامه عملی می‌تواند سه بازه داشته باشد:

۹۰ روز مانده به Warranty Expiry: Review؛
۶۰ روز مانده: تصمیم Extend/Replace؛
۳۰ روز مانده: اجرای اقدام نهایی.

عدد روزها باید با فرآیند خرید سازمان تنظیم شود، نه به‌صورت ثابت برای همه شرکت‌ها.

Lease و Loan را با مالکیت دائمی اشتباه نگیرید

بعضی Assetها خریداری نشده‌اند؛ Lease یا Loan هستند. برای این دارایی‌ها Return Date، Vendor و Contract اهمیت بیشتری از Depreciation داخلی دارند.

اگر Contract پایان یابد اما Asset همچنان In Use باقی بماند، سازمان ممکن است هزینه اضافی یا ریسک قراردادی داشته باشد. بنابراین Lifecycle Policy باید بر اساس Acquisition Type متفاوت باشد.

Repair State باید Cost تولید کند، نه فقط Status

اگر یک لپ‌تاپ در طول سه سال چهار بار Repair شده اما هزینه تعمیر در Asset Record دیده نمی‌شود، تصمیم Replacement مبتنی بر داده نخواهد بود.

برای Assetهای Under Repair این اطلاعات مفیدند:

Repair Date؛
Failure Type؛
Vendor؛
Cost؛
Warranty Coverage؛
Downtime؛
Return-to-Service Date.

بعد می‌توان Rule ساخت: وقتی Repair Cost یا Frequency از حد اقتصادی عبور کرد، Asset Candidate Retirement شود.

Asset Lifecycle و CMDB چه رابطه‌ای دارند؟

Asset و CI یک مفهوم نیستند، هرچند یک Device می‌تواند هر دو باشد. Asset Management روی مالکیت، هزینه، قرارداد و چرخه اقتصادی تمرکز دارد؛ CMDB روی نقش Configuration Item در ارائه سرویس و Relationshipها.

در AssetExplorer، CMDB یکپارچه کمک می‌کند Asset فقط به‌عنوان «لپ‌تاپ شماره ۴۵» دیده نشود؛ بلکه Relationship آن با User، Service، Server یا سایر CIها نیز قابل تحلیل باشد.

در نسخه Cloud، ManageEngine Sync Rule برای اضافه شدن Assetهای کشف‌شده به CMDB و به‌روز ماندن Relationship Map معرفی کرده است.

Asset Lifecycle و Cyber Asset Management چه تفاوتی دارند؟

مقاله مدیریت دارایی سایبری با AssetExplorer روی Discovery، دارایی ناشناخته، Criticality و Attack Surface تمرکز دارد. مقاله حاضر Intent دیگری دارد: چرخه عملیاتی و مالی Asset از Procurement تا Disposal.

این دو مکمل هم هستند:

Cyber Asset Management می‌پرسد: چه دارایی‌هایی داریم و کدام برای امنیت مهم‌اند؟
Lifecycle Management می‌پرسد: این دارایی در چه مرحله‌ای است، مالک آن کیست و قدم بعدی چیست؟

Asset Lifecycle و Software Asset Management چه تفاوتی دارند؟

Software Asset Management روی License، Software Inventory، Compliance و Usage تمرکز دارد. اگر مسئله شما کاهش هزینه نرم‌افزار و کنترل License Compliance است، مقاله Software Asset Management در AssetExplorer مسیر تخصصی آن را پوشش می‌دهد.

در Lifecycle سخت‌افزار، تمرکز اصلی روی Device Ownership، State، Cost، Warranty، Repair، Reclamation و Disposal است.

Barcode و Asset Tag چه نقشی در چرخه عمر دارند؟

هرچه Asset بیشتر جابه‌جا شود، اتکا به Hostname یا IP خطرناک‌تر می‌شود. Hostname تغییر می‌کند، IP Dynamic است و حتی Disk Image ممکن است Device Identity را گیج کند.

Asset Tag، Serial Number و Barcode باید بخشی از Identity پایدار Asset باشند. مستندات Database Schema ManageEngine نیز فیلدهایی مانند Asset Tag، Serial Number، Barcode، Acquisition Date و Warranty Expiry را برای Assetها نشان می‌دهد.

در عملیات انبار و تحویل، Barcode/QR می‌تواند Check-in و Check-out را سریع‌تر و خطای انسانی را کمتر کند؛ البته طراحی دقیق Mobile/Barcode Workflow باید با Edition و Build واقعی محصول تطبیق داده شود.

Disposal فقط تغییر State به Disposed نیست

دارایی Retired یا Disposed می‌تواند هنوز داده سازمانی داشته باشد. بنابراین Disposal Process باید امنیت، مالی و Compliance را هم‌زمان ببیند.

مرحله Disposal	کنترل پیشنهادی
Business Approval	تأیید اینکه Asset دیگر ارزش عملیاتی ندارد
Data Handling	Backup لازم و سپس Secure Wipe/Destruction
License Recovery	بازپس‌گیری Licenseهای قابل انتقال
Accessory Check	جمع‌آوری قطعات و تجهیزات همراه
Financial Closure	ثبت Disposal Value/Write-off طبق سیاست مالی
Evidence	ثبت تأیید و مستند خروج دارایی
State Update	Retired/Disposed و جلوگیری از تخصیص مجدد

چه KPIهایی برای Asset Lifecycle مناسب‌اند؟

اگر فقط Total Asset Count را گزارش کنید، Lifecycle Quality مشخص نمی‌شود. KPIهای بهتر:

درصد Assetهای دارای Owner معتبر؛
درصد Assetهای دارای Location معتبر؛
درصد Assetهای بدون State نامشخص؛
Average Time از Receive تا Assignment؛
Average Time از Offboarding تا Reclamation؛
Asset Reuse Rate؛
تعداد Assetهای Past-due برای Return؛
Warranty Expiring in 30/60/90 Days؛
Repair Cost per Asset؛
Disposed Asset with Missing Evidence؛
Inventory-to-PO Reconciliation Rate.

سناریوی ۱: Onboarding سریع بدون خرید اضافه

HR اعلام می‌کند ۲۰ نیروی جدید در ماه آینده اضافه می‌شوند. قبل از Purchase Request، ITAM Dashboard نشان می‌دهد ۷ لپ‌تاپ Reclaimed و ۵ لپ‌تاپ In Stock داریم. پس فقط ۸ دستگاه جدید لازم است.

این تصمیم فقط وقتی ممکن است که State و Condition دارایی‌ها واقعی باشند. اگر Reclaimed Assetها هنوز به User قبلی Assign مانده باشند، تیم خرید تصویر درستی ندارد.

سناریوی ۲: Offboarding با Zero Missing Asset

کارمند استعفا می‌دهد. Workflow خروج باید ابتدا تمام Assetهای مرتبط را استخراج کند. لپ‌تاپ، Dock، Monitor و Token تا قبل از Clearance نهایی باید Status مشخص داشته باشند.

بعد از Return، Assetها به‌جای انتقال مستقیم به User بعدی وارد Inspection می‌شوند. Device سالم به In Stock می‌رود؛ Device خراب به Under Repair؛ Device قدیمی به Retirement.

این ساختار باعث می‌شود Offboarding از یک Checklist انسانی پراکنده به Process قابل Audit تبدیل شود.

سناریوی ۳: Warranty Wave قبل از بحران بودجه

گزارش AssetExplorer نشان می‌دهد تعداد زیادی Laptop در یک Quarter از Warranty خارج می‌شوند. به‌جای اینکه خرابی‌ها بعداً به Purchase Emergency تبدیل شوند، سازمان می‌تواند Replacement Plan را چند ماه زودتر وارد Budget کند.

Lifecycle Data در اینجا از یک ابزار IT به ورودی تصمیم مالی تبدیل می‌شود.

سناریوی ۴: Assetی که در Scan هست اما Owner ندارد

Network Scan یک Device فعال پیدا می‌کند، اما Asset Record Owner ندارد. این وضعیت باید Exception باشد. دستگاه فعال بدون Owner می‌تواند نشانه جابه‌جایی ثبت‌نشده، Asset ناشناخته یا ضعف در Offboarding باشد.

در چنین مواردی Lifecycle و Cyber Asset Management به هم می‌رسند: Data Quality پایین ITAM می‌تواند Risk امنیتی تولید کند.

چطور Asset Lifecycle را مرحله‌ای پیاده کنیم؟

فاز اول: State Dictionary

قبل از Automation، Stateهای استاندارد را تعریف کنید. از ساختن ۳۰ State مشابه خودداری کنید. هر State باید معنای عملیاتی و Owner داشته باشد.

فاز دوم: Data Quality

Asset Tag، Serial، Owner، Location، Acquisition Date، Warranty و State را پاک‌سازی کنید. Workflow روی داده بد فقط خطا را سریع‌تر می‌کند.

فاز سوم: Onboarding/Offboarding

Allocation و Reclamation را استاندارد کنید. این دو فرآیند معمولاً بیشترین اثر سریع را دارند.

فاز چهارم: Contract و Warranty

Expiry Notification و Renewal/Replacement Review را وارد چرخه کنید.

فاز پنجم: Repair و Disposal

هزینه تعمیر، Condition، Retirement Rule و Data Disposal Evidence را رسمی کنید.

فاز ششم: Automation

پس از تثبیت Process، در نسخه‌ها و Editionهایی که پشتیبانی می‌کنند از Workflow، Custom Action، Notification و Integration برای کاهش کار دستی استفاده کنید.

POC را با چند Asset واقعی اجرا کنید

در زمان نگارش این مقاله، صفحه رسمی Download AssetExplorer برای On-Premises یک Trial سی‌روزه با ظرفیت ۲۵۰ IT Asset و Free Edition با محدودیت ۲۵ Node را اعلام می‌کند. این ظرفیت برای یک Pilot کنترل‌شده مناسب است؛ اما شرایط Licensing باید پیش از خرید نهایی با نسخه و Quote روز بررسی شود.

در POC فقط Scan را تست نکنید. حداقل این سناریوها را اجرا کنید:

Receive یک Asset؛
Assign به User؛
Transfer بین User یا Site؛
Change State به Under Repair؛
Reclaim هنگام Offboarding؛
Return to Stock؛
Retire/Dispose؛
Warranty Expiry Report؛
PO/Asset Reconciliation؛
CMDB Relationship.

۱۰ خطای رایج در مدیریت چرخه عمر دارایی

استفاده از Excel به‌عنوان Source of Truth موازی.
نبود Asset Tag استاندارد.
ساخت Asset دوباره پس از Scan.
Assign کردن Device بدون Owner/Department.
نبود Return Date برای Loan Asset.
Offboarding بدون Asset Reclamation.
ندیدن Warranty و Contract Expiry.
ثبت Repair بدون Cost.
Dispose کردن بدون Secure Data Handling.
Automation قبل از پاک‌سازی Data Quality.

چک‌لیست اجرایی Asset Lifecycle

Stateهای استاندارد و بدون هم‌پوشانی تعریف شده‌اند.
Asset Tag و Serial Number اجباری یا کنترل‌شده‌اند.
PO و Asset دریافت‌شده Reconcile می‌شوند.
Assetهای In Stock Location مشخص دارند.
Assignment به User و Department ثبت می‌شود.
Loan Asset دارای Return Date است.
Offboarding به Reclamation Asset متصل است.
Asset Reclaimed قبل از Reassignment Inspection می‌شود.
Warranty Expiry Review وجود دارد.
Repair Cost ثبت می‌شود.
Retirement Rule تعریف شده است.
Disposal شامل Data Wipe و Evidence است.
CMDB Relationship در Assetهای حیاتی به‌روز است.
KPIهای Lifecycle ماهانه مرور می‌شوند.

نکات کلیدی

Inventory فقط می‌گوید چه دارایی‌هایی دارید؛ Lifecycle مشخص می‌کند هر Asset در چه مرحله‌ای است و قدم بعدی چیست.
Procurement و Discovery باید Reconcile شوند تا Duplicate Asset ساخته نشود.
Onboarding بدون Allocation ثبت‌شده و Offboarding بدون Reclamation، دو منبع اصلی Data Drift هستند.
Warranty، Contract، Repair Cost و Disposal بخشی از ITAM هستند، نه اطلاعات جانبی.
در AssetExplorer Cloud می‌توان Allocation و Reclamation را با Visual Workflow استاندارد کرد.
Asset Lifecycle، Software Asset Management و Cyber Asset Management سه لایه مکمل‌اند و نباید با هم خلط شوند.

AssetExplorer در معماری ITAM مدانت

برای بررسی Capabilityهای کامل محصول، صفحه AssetExplorer مدانت مرجع اصلی این Pillar است. اگر تمرکز شما روی کشف دارایی ناشناخته و Attack Surface است، مقاله مدیریت دارایی سایبری با AssetExplorer را ببینید. برای License Compliance و هزینه نرم‌افزار نیز مقاله Software Asset Management در AssetExplorer مسیر تخصصی جداگانه دارد.

برای استعلام خرید یا تمدید نیز استعلام قیمت لایسنس ManageEngine و برای بررسی معماری قبل از خرید درخواست جلسه فنی و دمو در دسترس است.

منابع

سخن پایانی

ITAM زمانی بالغ می‌شود که Asset از لحظه خرید تا لحظه خروج از سازمان یک مسیر قابل مشاهده داشته باشد. اگر فقط Discovery انجام شود اما Owner، State، Warranty، Repair، Reclamation و Disposal کنترل نشوند، Inventory خیلی زود با واقعیت فاصله می‌گیرد.

AssetExplorer می‌تواند این چرخه را در یک Repository مرکزی به Procurement، Contract، CMDB و Asset State متصل کند و در نسخه Cloud با Visual Workflow، Allocation و Reclamation را استانداردتر کند. ارزش واقعی این کار در Dashboard نیست؛ در این است که سازمان بداند چه چیزی دارد، دست چه کسی است، چه هزینه‌ای ایجاد می‌کند و در مرحله بعد چه تصمیمی باید درباره آن گرفته شود.

مدانت می‌تواند در استعلام و خرید لایسنس AssetExplorer، طراحی فرآیند ITAM، Discovery و Reconciliation، Asset Lifecycle، CMDB، Onboarding/Offboarding Asset Workflow، مهاجرت داده، استقرار، آموزش و پشتیبانی همراه سازمان باشد. برای بررسی Scope از تماس با مدانت یا درخواست جلسه فنی استفاده کنید.

3520