خرید لایسنس Endpoint Central فقط با شمردن کامپیوترهای سازمان انجام نمیشود. برای برآورد درست باید بدانید چند Endpoint و Server در Scope مدیریت قرار میگیرند، چند Technician به Console نیاز دارند، کدام Edition برای Use Case شما کافی است و Cloud یا On-Premises انتخاب میشود.
اشتباه در همین متغیرها میتواند باعث Over-Licensing یا کمبود لایسنس در Rollout شود. این راهنما مدل مجوز Endpoint Central را بر اساس اطلاعات رسمی ManageEngine و سناریوی واقعی خرید سازمانی توضیح میدهد؛ هدف اعلام یک قیمت ثابت نیست، چون قیمت و SKU میتواند تغییر کند، بلکه هدف این است که قبل از Quote دقیقاً بدانید چه چیزی باید شمرده و مقایسه شود.
Endpoint Central بر چه اساسی لایسنس میشود؟
در مدل فعلی، قیمتگذاری بر اساس تعداد Endpointها، Serverها، Edition و تعداد Technicianها انجام میشود. جدول رسمی ManageEngine پکیجهای مختلف Endpoint و Server را برای مدلهای On-Premises و Cloud نشان میدهد.
در نتیجه، جمله «شرکت ما ۱۰۰۰ کارمند دارد» برای Quote کافی نیست. باید تعداد Deviceهایی را که واقعاً قرار است مدیریت شوند استخراج کنید. اگر ۱۰۰۰ کارمند دارید ولی ۷۲۰ دستگاه در Scope است، نقطه شروع Sizing همان ۷۲۰ Endpoint است، نه Headcount سازمان.
چه چیزی Endpoint محسوب میشود؟
برای Sizing، Endpoint معمولاً دستگاهی است که تحت مدیریت Endpoint Central قرار میگیرد؛ مانند Desktop و Laptop و سایر Client Deviceهایی که محصول آنها را مدیریت میکند. Serverها در Price Matrix رسمی بهصورت بخش جداگانه دیده میشوند.
| نوع | در Sizing چه کنیم؟ |
|---|---|
| Desktop/Laptop | در تعداد Endpoint قرار دهید |
| Server | جداگانه در ظرفیت Server محاسبه کنید |
| دستگاه خارج از سرویس | قبل از Quote از Scope پاکسازی شود |
| آزمایشگاه/Pilot | اگر مدیریت دائمی میشود، در ظرفیت نهایی لحاظ شود |
| دستگاه شعبه | اگر تحت مدیریت است، از Inventory جا نماند |
Inventory را قبل از استعلام پاکسازی کنید
یکی از علتهای Quote اشتباه این است که Inventory خام مستقیماً به فروشنده داده میشود. دستگاهی که ماههاست Retired شده، رکورد Duplicate یا سیستم آزمایشگاهی موقت نباید بدون بررسی وارد Baseline Production شود.
Inventory را با AD، Endpoint Inventory، فهرست خرید و اطلاعات شعب تطبیق دهید. اگر اختلاف زیاد است، قبل از سفارش یک Discovery/Pilot محدود انجام دهید. کیفیت Sizing مستقیماً به کیفیت Inventory وابسته است.
Technician در Endpoint Central چه نقشی در لایسنس دارد؟
بستههای پایه تعداد مشخصی Technician دارند و Technician اضافی میتواند آیتم مستقل Quote باشد. اگر چند Admin یا تیم Endpoint، Security و Branch Operations باید به Console دسترسی داشته باشند، تعداد Technician باید قبل از سفارش مشخص شود.
یکی از خطاهای رایج این است که در POC فقط یک Admin کار میکند اما در Production پنج یا ده نفر نیاز به دسترسی دارند. Quote آزمایشی در این حالت با هزینه واقعی Rollout تفاوت خواهد داشت.
Professional، Enterprise، UEM یا Security؛ کدام Edition؟
انتخاب Edition باید از Use Case بیاید. سازمانی که فقط Patch، Software Deployment و Remote Management پایه میخواهد ممکن است نیاز متفاوتی با سازمانی داشته باشد که UEM، مدیریت گسترده Deviceها یا قابلیتهای امنیتی اضافه میخواهد.
به جای انتخاب Edition بر اساس نام، Feature Matrix رسمی را با سه ستون Must Have، Should Have و Nice to Have بررسی کنید. هر Feature که برای Compliance، عملیات یا معماری اجباری است باید قبل از Quote مشخص شود.
یک ماتریس ساده برای انتخاب Edition
| نیاز | نوع تصمیم |
|---|---|
| Patch و Software Management پایه | Editionهای پایه را بررسی کنید |
| چند Site و نیازهای Enterprise Management | Enterprise Feature Matrix را بررسی کنید |
| UEM و Device Scope گسترده | UEM Edition را با Scope واقعی تطبیق دهید |
| قابلیتهای Security اضافه | Security Edition/Add-onها را جدا بررسی کنید |
این جدول جای Feature Matrix رسمی را نمیگیرد؛ فقط کمک میکند قبل از تماس تجاری، سؤال درست داشته باشید.
Cloud یا On-Premises؟
Endpoint Central در هر دو مدل ارائه میشود. تفاوت فقط محل نصب نیست. Cloud مسئولیت زیرساخت محصول را کمتر میکند، در حالی که On-Premises کنترل بیشتری روی استقرار داخلی و بعضی Integrationهای محلی میدهد. انتخاب باید بر اساس Security Policy، Data Residency، شبکه شعب، اینترنت و ظرفیت تیم زیرساخت انجام شود.
در سازمانهای چندشعبهای، قبل از خرید فقط سؤال «Cloud یا On-Prem» کافی نیست؛ باید مسیر ارتباط Remote Officeها، پهنای باند، Distribution Architecture و تجربه عملیاتی تیم نیز بررسی شود.
Annual یا Perpetual؟
در Pricing رسمی Endpoint Central برای On-Premises مدلهای Annual و Perpetual ارائه میشود. در مدل Perpetual، AMS نیز باید در TCO دیده شود. بنابراین مقایسه فقط قیمت سال اول تصویر درستی نمیدهد.
برای تصمیم مالی، حداقل یک افق سهساله بسازید و هزینه خرید، تمدید، AMS، رشد ظرفیت، خدمات استقرار و پشتیبانی را کنار هم بگذارید. مقاله انقضای AMS ManageEngine اثر تمدید و Upgrade را جداگانه توضیح میدهد.
نمونه Sizing برای سازمان ۸۰۰ کاربره
فرض کنید سازمان ۸۰۰ کاربر، ۶۵۰ لپتاپ/دسکتاپ، ۷۵ Server و ۶ Technician عملیاتی دارد. Sizing نباید روی ۸۰۰ User انجام شود؛ Scope واقعی مدیریت یعنی Endpointها، Serverها و Technicianها ملاک است.
- ۶۵۰ Endpoint فعال را ثبت کنید.
- ۷۵ Server را جداگانه محاسبه کنید.
- ۶ Technician را در Quote لحاظ کنید.
- Edition را بر اساس قابلیتهای واقعی انتخاب کنید.
- برای رشد ۱۲ تا ۱۸ ماه آینده ظرفیت در نظر بگیرید.
Growth Buffer چقدر باشد؟
هیچ درصد جادویی برای همه سازمانها وجود ندارد. سازمانی که استخدام ثابت دارد با شرکتی که دو شعبه جدید افتتاح میکند یکسان نیست. Growth Buffer را از برنامه واقعی Procurement، استخدام، M&A و Refresh Plan استخراج کنید.
ظرفیت اندکی بالاتر از Baseline میتواند منطقی باشد، اما خرید چند برابر نیاز امروز فقط به امید رشد نامشخص، سرمایه را قفل میکند.
POC را با Scope خرید یکی کنید
POC زمانی ارزش تجاری دارد که Edition و قابلیتهای فعالشده آن با Quote نهایی قابل تطبیق باشند. اگر در POC قابلیتهای Edition بالاتر یا Add-on فعال بوده و در Quote حذف شده باشد، تیم بعد از خرید تصور میکند محصول بخشی از قابلیتهای آزمایششده را از دست داده است.
در گزارش POC بنویسید هر Use Case با کدام Edition یا Add-on تأمین شده است.
Quote حرفهای چه ستونهایی باید داشته باشد؟
| فیلد | چرا مهم است؟ |
|---|---|
| Product/SKU | جلوگیری از مقایسه محصولات متفاوت |
| Edition | مشخصشدن Feature Scope |
| Endpoint Quantity | ظرفیت Client |
| Server Quantity | ظرفیت Server |
| Technician | تعداد دسترسی مدیریتی |
| Contract | Annual یا Perpetual |
| AMS/Support | هزینه نگهداری و Upgrade |
| Add-on | جلوگیری از اختلاف Scope |
خطاهای رایج خرید لایسنس Endpoint Central
- شمردن User به جای Endpoint؛
- فراموشکردن Serverها؛
- نادیدهگرفتن Technicianهای اضافه؛
- انتخاب Edition صرفاً بر اساس قیمت؛
- محاسبه نکردن AMS در مدل Perpetual؛
- نادیدهگرفتن Cloud/On-Premises Architecture؛
- استفاده از Inventory قدیمی؛
- ندیدن رشد نزدیک سازمان؛
- مقایسه Quoteهایی که Add-on یکسان ندارند.
لایسنس Endpoint Central را با محصولات دیگر اشتباه نکنید
هر محصول ManageEngine Metric متفاوت دارد. مثلاً ADManager Plus بر اساس Domain و Technician و Applications Manager بر اساس Monitor Sizing میشود. استفاده از یک فرمول واحد برای کل خانواده ManageEngine اشتباه است.
راهنمای مادر خرید لایسنس ManageEngine تفاوت Metricها، Edition، Subscription، Perpetual و AMS را یکجا جمعبندی کرده است.
چکلیست قبل از خرید
- Inventory Endpoint بهروز است.
- Serverها جدا شمارش شدهاند.
- Technicianهای واقعی مشخصاند.
- Edition بر اساس Feature Matrix انتخاب شده است.
- Cloud/On-Premises تصمیمگیری شده است.
- Annual/Perpetual و AMS مقایسه شدهاند.
- رشد ۱۲ تا ۱۸ ماه آینده دیده شده است.
- POC با Scope Quote نهایی تطبیق دارد.
- Quote دارای SKU و Scope دقیق است.
برای دریافت Quote مبتنی بر Sizing واقعی، مرکز استعلام و خرید مدانت را میتوانید با Inventory و Use Case سازمان تکمیل کنید.
نکات کلیدی
Endpoint، Server، Technician و Edition چهار متغیر اصلی Sizing هستند. قیمت عمومی یا تعداد کارکنان بهتنهایی برای تصمیم خرید کافی نیست. Quote باید به معماری و Inventory واقعی متصل باشد.
سخن پایانی
لایسنس Endpoint Central زمانی بهینه است که از Inventory واقعی شروع شود، نه تعداد کارکنان. اگر Endpoint، Server، Technician، Edition و مدل قرارداد دقیق باشند، هم بودجه قابل دفاعتر میشود و هم احتمال خرید اضافه یا کمبود لایسنس در Rollout کاهش مییابد.
