موعد تمدید یک نرمافزار تخصصی رسیده است. فهرست موجودی نشان میدهد برنامه روی دهها رایانه نصب است، اما مدیر واحد میگوید فقط بخشی از کارکنان از آن استفاده میکنند. تیم خرید تعداد نصب را مبنای سفارش میگیرد و تیم فنی تعداد ورود کاربران را پیشنهاد میکند. هیچکدام هنوز نمیدانند کدام مجوز واقعاً لازم است و درباره کدام دستگاه، اصلاً داده قابل اتکایی ندارند.
سنجش مصرف نرمافزار این فاصله را با مشاهده استفاده واقعی کمتر میکند؛ به شرط آنکه قاعده جمعآوری درست تعریف شده باشد و نتیجه با نیاز کاری تفسیر شود. این راهنما بر قابلیت Software Metering در ManageEngine Endpoint Central و اجرای آن برای برنامههای ویندوزی تمرکز دارد. هدف، تولید شاهد برای تصمیم خرید و نگهداری است، نه رتبهبندی عملکرد کارکنان بر اساس زمان باز بودن برنامه.
نصب بودن، استفاده شدن و نیاز داشتن یکسان نیستند
یک برنامه ممکن است نصب باشد اما فقط هنگام بستن حسابهای پایان فصل استفاده شود. برنامه دیگری شاید هر روز اجرا شود، ولی بیشتر وقت در پسزمینه باز بماند. در هر دو حالت، تصمیم درباره ادامه مجوز به اطلاعاتی بیشتر از یک عدد نیاز دارد.
برای شروع، سه پرسش را جدا کنید: چه نرمافزاری روی کدام دستگاه وجود دارد، چه استفادهای از آن ثبت شده و چه نیاز تأییدشدهای برای دوره بعد وجود دارد؟ موجودی فنی پاسخ پرسش نخست است؛ داده مصرف به پرسش دوم کمک میکند و مسئول کسبوکار باید پرسش سوم را پاسخ دهد. ترکیب این سه، مبنای تصمیم است.
گزارش مصرف در محصول چه چیزی نشان میدهد؟
در معرفی رسمی Software Metering، ثبت مصرف توسط عامل و گزارشهای خلاصه قواعد، رایانهها و کاربران توضیح داده شده است. گزارش خلاصه، تعداد دستگاههای دارای نصب، شمار استفاده و مدت استفاده را نشان میدهد. نماهای رایانه و کاربر نیز بررسی مصرف در سطح دستگاه یا هویت را ممکن میکنند؛ این تفاوت برای کاربری که روی چند رایانه کار میکند مهم است.
| داده | کاربرد درست | برداشت نادرست |
|---|---|---|
| تعداد نصب کشفشده | شناخت دامنه فنی برنامه | همه نصبها به یک نوع مجوز نیاز دارند |
| شمار استفاده | بررسی تکرار اجرای برنامه | هر اجرا معادل یک کار مفید است |
| مدت استفاده ثبتشده | مقایسه الگوی مصرف در بازه مشخص | زمان ثبتشده برابر بهرهوری کارمند است |
| گزارش بر اساس رایانه | بررسی دستگاههای کممصرف یا مشترک | هر رایانه همیشه فقط یک کاربر دارد |
| گزارش بر اساس کاربر | مشاهده استفاده هویت در دستگاههای مختلف | حساب مشترک، هویت دقیق همه افراد را نشان میدهد |
این شاخصها نشانه فنی هستند. تعریف «استفاده مؤثر» باید برای هر برنامه با آزمون و نیاز سازمان روشن شود. ابزار اندازهگیری را جای تأیید مدیر واحد، شناخت فرایند یا بررسی شرایط مجوز قرار ندهید.
قاعده را برای برنامه واقعی بسازید
طبق راهنمای تنظیم قواعد، باید نرمافزار کشفشده، نام یکتای قاعده و نام دقیق فایل اجرایی مشخص شوند. برای ویندوز، نام فایل با پسوند EXE از بخش Details در Task Manager قابل بررسی است. مسیر معرفیشده در کنسول، Inventory، سپس Actions/Settings و Software Metering است؛ در بخش قواعد میتوان Add Rule را انتخاب کرد. این راهنما تعریف قاعده برای گروهی از نرمافزارها را مجاز نمیداند.
پیشنهاد عملی این است که پیش از ثبت قاعده، کاربر نمونه همان کاری را انجام دهد که قصد سنجش آن را دارید. میان راهانداز برنامه، ابزار بهروزرسانی و پردازش اصلی تفاوت بگذارید. ممکن است میانبر دسکتاپ فقط یک راهانداز را باز کند و کار اصلی در فایل دیگری انجام شود. انتخاب نام مشابه، بدون آزمون، گزارش ظاهراً مرتب اما نامعتبر تولید میکند.
نسخه و کاربرد را در نام قاعده روشن کنید
نامی مانند «مصرف برنامه طراحی در رایانههای مهندسی» از «قاعده یک» قابل نگهداریتر است. در پرونده اجرا، نام فایل، محصول، نسخههای آزمودهشده، مسئول و تاریخ شروع را ثبت کنید. این پرونده پیشنهادی برای کنترل تغییر است و نباید همه اجزای آن را فیلد آماده محصول فرض کرد.
پس از ارتقای برنامه، قاعده را دوباره آزمایش کنید. تغییر نام فایل یا جدا شدن یک ابزار جانبی میتواند پوشش سنجش را عوض کند. قاعدهای که یکبار درست کار کرده، بدون آزمون پس از تغییر، تضمین دائمی صحت داده نیست.
گزارش بلافاصله پس از ساخت قاعده کامل نمیشود
راهنمای رسمی، شروع سنجش را از چرخه بازآوری بعدی عامل، با فاصله معمول ۹۰ دقیقه، و ارسال داده را روزی یکبار توضیح میدهد؛ بنابراین نتیجه از روز بعد قابل بررسی است. همچنین نگهداری ۹۰ روز اخیر را برای گزارش ذکر میکند. این زمانبندیها را با نسخه و وضعیت ارتباط دستگاه تطبیق دهید.
در اجرای آزمایشی، ساخت قاعده و دیدن گزارش خالی در همان ساعت را شکست قطعی تلقی نکنید. زمان تعریف، دریافت قاعده، اجرای برنامه و مشاهده نتیجه را ثبت کنید. برای دستگاه دورکار نیز اول مطمئن شوید ارتباط و گزارشدهی در بازه بررسی برقرار بوده است؛ انتظار از چرخه معمول، با دادهای که هنوز نرسیده یکسان نیست.
صفر مصرف را از نبود داده جدا کنید
پیش از قرار دادن دستگاه در فهرست «بدون استفاده»، پوشش قاعده، سلامت عامل، بازه زمانی و هویت دستگاه را بررسی کنید. لپتاپی که مدت زیادی خاموش بوده یا تازه به سامانه مدیریت اضافه شده، شاهد کافی برای تصمیم کاهش مجوز ندارد. نام صحیح فایل نیز بخشی از همین بررسی است.
| وضعیت | تفسیر اولیه | اقدام پیشنهادی |
|---|---|---|
| مصرف صفر با پوشش تأییدشده | نامزد بررسی نیاز | تأیید مسئول واحد و بررسی کارهای دورهای |
| گزارش خالی در دستگاه قطعارتباط | اطلاعات ناکافی | رفع مشکل گزارشدهی پیش از تصمیم |
| مصرف کم در نرمافزار تخصصی | نیاز کمتکرار اما احتمالاً مهم | سنجش اهمیت و امکان دسترسی جایگزین |
| مصرف بالا در حساب مشترک | هویت مصرفکننده مبهم | اصلاح شیوه تحلیل، نه نسبت دادن مصرف به یک فرد |
| افت ناگهانی پس از ارتقا | احتمال تغییر مسیر اجرا | آزمون دوباره نام فایل و قاعده |
این جدول، وضعیتهای پیشنهادی برای تحلیل است؛ نام گزارشهای آماده کنسول نیست. اهمیت آن در این است که «اطلاعات نداریم» در گزارش مدیریتی به «نیازی وجود ندارد» تبدیل نشود.
بازه سنجش باید چرخه کاری را ببیند
یک هفته کمکار نمیتواند بهتنهایی مصرف سالانه نرمافزار مالی یا مهندسی را نمایندگی کند. دوره مشاهده را با فصل کاری، پروژه فعال و موعد تمدید هماهنگ کنید. برای برنامهای که فقط هنگام بحران لازم میشود، کمبودن مصرف ممکن است کاملاً طبیعی باشد؛ تصمیم نگهداری آن باید با نقش آن در تداوم خدمت توجیه شود.
اگر مقایسه طولانیتر لازم است، خروجی دورهای گزارش را با تاریخ، دامنه و روش ثابت در محل کنترلشده نگه دارید. آن را به یک مخزن نامحدود از رفتار افراد تبدیل نکنید. هدف و مدت نگهداری باید روشن باشد و دسترسی گزارش تفصیلی فقط به نقشهای لازم داده شود.
از داده مصرف تا تصمیم درباره مجوز
در جلسه بازبینی، نام برنامه، دامنه نصب، کیفیت پوشش، الگوی مصرف، نیاز آینده و تصمیم مسئول را کنار هم بگذارید. نتیجه میتواند ادامه استفاده، انتقال مشروط، بررسی بسته مناسبتر یا حذف کنترلشده برنامه باشد. کممصرف بودن فقط یک ورودی تصمیم است.
تعداد نصب را بدون تطبیق با مدل مجوز، به تعداد قابل خرید تبدیل نکنید. مجوز کاربرمحور، دستگاهمحور یا همزمان، منطق شمارش یکسانی ندارند و امکان انتقال نیز باید با شرایط محصول بررسی شود. داده فنی مصرف به تصمیم کمک میکند، اما بهتنهایی حق انتقال یا انطباق قراردادی را اثبات نمیکند.
برای مرحله پس از تصمیم، راهنمای بازپسگیری مجوزهای بلااستفاده مکمل این مقاله است. تفاوت این دو مرحله مهم است: ابتدا شاهد معتبر جمع میکنیم؛ سپس درباره آزادسازی مجوز تصمیم میگیریم. مدیریت دارایی نرمافزاری نیز نگاه گستردهتر به موجودی و تعهدات را پوشش میدهد.
حذف برنامه باید مسیر بازگشت داشته باشد
فهرست کممصرفها را مستقیماً به حذف گروهی وصل نکنید. ابتدا تأیید مسئول برنامه، بررسی وابستگی فایلها و افزونهها، اطلاعرسانی به کاربر و امکان نصب دوباره را مشخص کنید. یک اجرای محدود میتواند نشان دهد آیا برنامه فرعی یا قالبی به نصب موجود وابسته بوده است.
در سازمان دارای سرویس دسک پلاس، میتوان تصمیم و درخواست تغییر را در فرایند پشتیبانی ثبت کرد. اتصال خودکار داده مصرف به این گردش کار، نیازمند طراحی و بررسی امکانات نسخه است؛ ثبت گزارش در یک سامانه، بهخودیخود مجوز حذف در سامانه دیگر نمیسازد.
آزمون پذیرش و شاخصهای مفید
یک برنامه منتخب را روی دستگاه آزمایشی اجرا کنید و پس از چرخه گزارشدهی، نتیجه را کنترل کنید. سپس یک نمونه بدون اجرا و یک دستگاه با وقفه ارتباط را مقایسه کنید. انتظار این نیست که همه جزئیات گزارش عیناً با زمانسنج دستی برابر باشند؛ باید تعریف شاخص و رفتار آن برای تیم روشن شود.
در گزارش مدیریتی، سهم دستگاههای دارای داده معتبر، قواعد آزمودهشده، تصمیمهای منتظر تأیید و موارد بازگشت پس از حذف را نشان دهید. صرفهجویی فقط وقتی گزارش شود که هزینه واقعی تمدید یا خرید کاهش یافته باشد؛ شمار «نامزدهای حذف» صرفهجویی تحققیافته نیست.
نکات کلیدی
- قاعده باید فایل اجرایی واقعی را دنبال کند، نه صرفاً نام آشنای برنامه را.
- داده مصرف با تأخیر گزارش میشود؛ زمانبندی را در تحلیل لحاظ کنید.
- مصرف صفر بدون اثبات پوشش، دلیل کافی برای حذف نیست.
- تصمیم مجوز باید نیاز کاری، شرایط استفاده و مسیر بازگشت را هم ببیند.
سخن پایانی
سنجش مصرف نرمافزار زمانی ارزش دارد که از یک نمودار به تصمیم قابل دفاع برسد. تعریف قاعده درست، شناخت محدودیت داده و تأیید نیاز کسبوکار، مانع دو خطای پرهزینه میشود: تمدید بیدلیل و حذف برنامهای که هنوز برای کار سازمان ضروری است.
مدانت برای انتخاب لایسنس و استقرار Endpoint Central، طراحی موجودی، قواعد سنجش و آموزش تیم مدیریت تجهیزات خدمات ارائه میدهد. در جلسه فنی مدانت، ارزیابی را با یک برنامه پرهزینه و چند دستگاه نماینده آغاز کنید تا کیفیت داده پیش از تصمیم خرید روشن شود.
منابع
- ManageEngine؛ تنظیم قواعد، چرخه گزارشدهی و نگهداری داده مصرف
- ManageEngine؛ گزارشهای مصرف بر اساس نرمافزار، رایانه و کاربر
