برای شروع Private AI، خرید زیرساخت تنها گزینه قابل بررسی نیست. سازمان میتواند متناسب با نیاز خود، زیرساخت را بهصورت سرویس دریافت کند. این انتخاب زمانی ارزش دارد که ظرفیت تحویلی، هزینه، شرایط توسعه و مسئولیت دو طرف روشن باشد. زیرساخت اختصاصی نیز باید با همین دقت بررسی شود تا تصمیم از شرایط واقعی مجموعه بیاید.
در این راهنما، موضوع از چند زاویه بررسی میشود: ابتدا مشخص کنیم دقیقاً چه چیزی دریافت میکنیم، نیاز امروز را از مصرف احتمالی آینده جدا کنیم، هزینه یک بازه یکسان را کنار هم بگذاریم. هدف این است که مخاطب پس از مطالعه، معیارهای تصمیمگیری و اقدام بعدی را روشنتر ببیند.
در این مقاله میخوانید
- ابتدا مشخص کنیم دقیقاً چه چیزی دریافت میکنیم
- نیاز امروز را از مصرف احتمالی آینده جدا کنیم
- هزینه یک بازه یکسان را کنار هم بگذاریم
- مالکیت تجهیزات و اختیار مدیریتی را جدا بررسی کنیم
ابتدا مشخص کنیم دقیقاً چه چیزی دریافت میکنیم
مدیر فناوری از دو ارائهدهنده میخواهد پیشنهادشان را بر اساس یک شرح نیاز کوتاه بازنویسی کنند. چه میزان ظرفیت اولیه لازم است؟ محیط برای چه مدت استفاده خواهد شد؟ چه سطحی از دسترسی باید در اختیار سازمان باشد؟ پاسخگویی هنگام مشکل چه دامنهای دارد؟ تا این موارد یکسان نشوند، ارزانتر بودن یک پیشنهاد میتواند صرفاً ناشی از کوچکتر بودن دامنه آن باشد.
در دریافت زیرساخت بهصورت سرویس، سازمان به منابع پایهای برای انجام فعالیت خود دسترسی میگیرد. لازم است پیشنهاد مشخص کند پردازش، فضای ذخیرهسازی، ارتباطات و پشتیبانی چگونه ارائه میشوند. تعریف NIST از زیرساخت بهعنوان سرویس نیز همین سطح از منابع را از دیگر مدلهای خدمت متمایز میکند. [۱] برای مدیر خریدار، مهمترین نتیجه این تفکیک، روشن شدن موضوع تحویل است.
در پیشنهاد اختصاصی نیز فهرست تجهیزات کافی نیست. آمادهسازی، نصب، آزمون، آموزش مسئولان بهرهبرداری و مستندات باید مشخص باشند. ممکن است دو پیشنهاد از تجهیزات مشابه استفاده کنند، اما یکی فقط تأمین کالا باشد و دیگری راهاندازی و تحویل محیط را هم در بر بگیرد. مقایسه باید بر اساس نتیجه قابل تحویل انجام شود.
نیاز امروز را از مصرف احتمالی آینده جدا کنیم
در سازمان روایت ما، یک واحد آماده شروع است و دو واحد دیگر فقط احتمال استفاده در آینده را مطرح کردهاند. مدیر فناوری ترجیح میدهد از همین ابتدا برای همه ظرفیت بخرد. نگرانی او قابل درک است؛ نمیخواهد چند ماه بعد به کمبود منابع برسد. مدیر مالی اما نمیخواهد هزینه نیازهایی را پرداخت کند که هنوز زمان و مقدارشان معلوم نیست.
برای حل این اختلاف، نیازها در دو ستون ثبت میشوند. ستون اول، مصرف اولیه با مسئول و زمان شروع مشخص است. ستون دوم، نیازهای احتمالی با فرضهای مربوط به آنهاست. پیشنهاد پایه برای ستون اول تهیه میشود و مسیر توسعه برای ستون دوم توضیح داده میشود. این روش اجازه میدهد آینده دیده شود، بدون اینکه هر احتمال به هزینه قطعی امروز تبدیل شود.
دریافت سرویس در چنین شرایطی میتواند موضوع بررسی باشد، چون سازمان درباره ظرفیت اولیه و نحوه تغییر آن مذاکره میکند. بااینحال، امکان توسعه باید مستند شود. چه منابعی قابل افزایش است؟ افزایش به چه مقدار زمان نیاز دارد؟ آیا محدودیت یا تعهد حداقلی وجود دارد؟ پاسخها تعیین میکنند این گزینه برای شرایط سازمان چقدر انعطاف دارد.
هزینه یک بازه یکسان را کنار هم بگذاریم
مدیر مالی پیشنهاد میکند مقایسه برای یک بازه مشترک انجام شود. در مسیر اختصاصی، هزینه خرید بههمراه هزینه آمادهسازی و بهرهبرداری آن بازه دیده میشود. در مسیر سرویس، مبلغ پایه، خدمات تکمیلی و تغییرات احتمالی ظرفیت لحاظ میشود. درباره هر فرض هم نوشته میشود که قطعی است، نیاز به استعلام دارد یا وابسته به مقدار مصرف است.
برای مثال، ممکن است فضای استقرار آماده باشد و برای سازمان هزینه تازهای ایجاد نکند. نباید همان هزینه را صرفاً برای شبیه شدن جدول به نمونههای عمومی اضافه کرد. در مقابل، اگر توسعه برق یا آمادهسازی محل واقعاً لازم است، حذف آن مقایسه را ناقص میکند. هزینهها باید از وضعیت خود سازمان استخراج شوند.
درباره سرویس نیز باید پرسید چه چیزی با توقف استفاده همچنان هزینه ایجاد میکند. نگهداری داده، ظرفیت رزروشده یا تعهد دورهای ممکن است مستقل از استفاده فعال باشد. این شرایط به قرارداد هر ارائهدهنده بستگی دارد. عنوان «سرویس» بهخودیخود به معنای پرداخت صرفاً برای زمان مصرف یا امکان کاهش فوری مبلغ نیست.
یک پیشنهاد ارزانتر ممکن است محدودیت بیشتری در ظرفیت یا پشتیبانی داشته باشد. پیشنهاد گرانتر هم لزوماً ارزش بیشتری ایجاد نمیکند. جدول مقایسه زمانی به تصمیم کمک میکند که مدیر بتواند ببیند تفاوت مبلغ در برابر کدام تفاوت قابل استفاده در خدمت قرار گرفته است.
مالکیت تجهیزات و اختیار مدیریتی را جدا بررسی کنیم
یکی از مدیران میگوید: «اگر تجهیزات برای خودمان باشد، کنترل بیشتری داریم.» لازم است منظور از کنترل روشن شود. آیا سازمان میخواهد محل فیزیکی مشخصی داشته باشد؟ تغییرات زیرساخت فقط با تأیید خودش انجام شود؟ دسترسی مدیران محدود باشد؟ یا میخواهد مصرف و هزینه هر واحد را ببیند؟ هرکدام پاسخ و طراحی متفاوتی دارد.
ممکن است بخشی از این خواستهها در یک سرویس مناسب قابل تأمین باشد و بخشی نیاز به محیط اختصاصی داشته باشد. در مقابل، داشتن تجهیزات بدون فرایند روشن دسترسی و نگهداری، همه آن خواستهها را تأمین نمیکند. معیار باید به زبان قابل بررسی نوشته شود تا ارائهدهنده بتواند درباره امکان تأمین آن پاسخ مشخص بدهد.
در جلسه، مدیرعامل از تیم میخواهد بهجای عبارت کلی «کنترل کامل»، چند شرط بنویسد. چه کسی دسترسی مدیریتی دارد؟ سوابق فعالیت چگونه قابل پیگیری است؟ برای تغییر مهم چه هماهنگی انجام میشود؟ این سؤالها هم در خرید و هم در دریافت سرویس لازماند و کیفیت مقایسه را بالاتر میبرند.
زمان شروع و آمادگی تیم چه اثری دارند
سازمان برای شروع فعالیت موردنظر خود زمان محدودی دارد. در پیشنهاد اختصاصی باید زمان تأمین، آمادهسازی و آزمون مشخص شود. در پیشنهاد سرویس نیز زمان بررسی نیاز، ایجاد محیط، تنظیم دسترسی و پذیرش اهمیت دارد. هیچ مسیر را صرفاً به دلیل نام آن، سریعتر فرض نکنیم. برنامه تحویل باید با شرایط واقعی تأمینکننده بررسی شود.
همزمان، مدیر فناوری وضعیت تیم خود را توضیح میدهد. بخشی از نیروها درگیر نگهداری سامانههای فعلیاند. اگر محیط جدید به مسئولیت آنها اضافه شود، چه زمانی برای این کار خواهند داشت؟ آیا آموزش یا پشتیبانی بیشتری لازم است؟ این پرسشها باید قبل از تصویب زیرساخت اختصاصی پاسخ بگیرند.
در دریافت سرویس نیز سازمان به مسئول پیگیری نیاز دارد. باید کسی درخواستها را هماهنگ کند، دسترسیها را تأیید کند و هزینهها را ببیند. تفاوت مسیرها در میزان و نوع مسئولیت است. حذف کامل نقش داخلی از برنامه، حتی در یک سرویس مناسب، میتواند به سردرگمی پس از تحویل منجر شود.
مدل Multi-Tenant را در پیشنهاد درست بخوانیم
اگر ارائهدهنده، زیرساخت را با مدل Multi-Tenant عرضه میکند، باید توضیح دهد کدام منابع مشترکاند و محیط هر سازمان چگونه از دیگران تفکیک میشود. برای مدیران، نتیجه عملی مهم است: فعالیت یک سازمان چه اثری بر سازمان دیگر دارد و دسترسی به داده و محیط چگونه کنترل میشود؟
این مدل میتواند امکان استفاده از بخشی از یک بستر بزرگتر را فراهم کند. اما مقدار صرفهجویی یا سطح عملکرد به معماری، سهم منابع و شرایط خدمت وابسته است. نام مدل، جای شواهد تحویل را نمیگیرد. سازمان باید الزامات خود را بیان کند و درباره نحوه تأمین آنها پاسخ بگیرد.
در همین مرحله میتوان پرسید اگر بعداً نیاز به ظرفیت اختصاصی پیدا کردیم، چه گزینهای وجود دارد. گاهی یک بخش از محیط میتواند اختصاصی و بخش دیگری مشترک باشد. امکان و هزینه چنین ترکیبی باید در پیشنهاد مشخص شود؛ بهتر است آن را پیش از شروع بدانیم، نه زمانی که نیاز جدید فوریت پیدا کرده است.
تحویل را با چند معیار قابل مشاهده تعریف کنیم
مدیر فناوری پیشنهاد میکند پیش از تصمیم نهایی، معیارهای پذیرش نوشته شود. محیط موردتوافق در دسترس باشد، افراد مجاز بتوانند وارد شوند، ظرفیت تعیینشده ارائه شود و مسیر ثبت درخواست مشخص باشد. هر معیاری که برای سازمان حیاتی است باید با روش بررسی خودش همراه شود.
اگر زمان انجام کار اهمیت دارد، بررسی باید با یک نمونه نماینده از فعالیت سازمان انجام شود. نتیجه یک نمایش کوتاه یا استفاده بسیار سبک، بهتنهایی نشان نمیدهد محیط برای بار موردنظر مناسب است. داده و روش آزمون نیز باید مجاز و متناسب با حساسیت اطلاعات انتخاب شود.
پیشنهاد اختصاصی و سرویس میتوانند روش تحویل متفاوتی داشته باشند، اما انتظار سازمان باید روشن بماند. وجود تجهیزات یا ایجاد یک حساب کاربری، بهتنهایی معیار پایان کار نیست. تحویل وقتی معنا دارد که آنچه برای شروع توافق شده، قابل استفاده و قابل پیگیری باشد.
هزینه تغییر تصمیم را از ابتدا بپرسیم
مدیرعامل میپرسد اگر شش ماه بعد نیاز تغییر کرد چه میشود. در زیرساخت اختصاصی، باید هزینه توسعه یا تغییر تجهیزات را در نظر گرفت. در سرویس، شرایط افزایش، کاهش یا پایان همکاری اهمیت پیدا میکند. این پرسش به معنای بیاعتمادی نیست؛ بخشی از تصمیمی است که باید تغییرات کسبوکار را تحمل کند.
درباره سرویس، امکان دریافت اطلاعات سازمان در قالب قابل استفاده، زمان انتقال و روش بستن دسترسیها باید روشن باشد. راهنمای NIST نیز برنامه خروج را بخشی از بررسی پیش از انتخاب خدمت میداند. [۲] قرار نیست تمام جزئیات انتقال آینده امروز اجرا شود، اما مسیر و مسئولیت آن نباید نامعلوم بماند.
برای زیرساخت اختصاصی هم باید سازگاری و وابستگیها مستند باشد. اگر توسعه به یک خانواده محدود از تجهیزات وابسته است، مدیر تصمیمگیر باید آن را بداند. هزینه تغییر مسیر، یکی از عوامل مقایسه است و میتواند نتیجهای متفاوت از مقایسه مبلغ خرید اولیه ایجاد کند.
جلسه مقایسه به چه نتیجهای برسد
مدیران سازمان در پایان جلسه هنوز برند تجهیزات را انتخاب نکردهاند، اما تصویر روشنتری دارند. آنها نیاز اولیه را از آینده احتمالی جدا کردهاند، دو پیشنهاد را با دامنه یکسان میخواهند و برای هزینه، دسترسی، زمان تحویل و توسعه سؤال مشخص دارند. حالا هر پیشنهاد باید پاسخ همین موارد را نشان دهد.
ممکن است نتیجه بررسی، دریافت سرویس برای مرحله نخست باشد. ممکن است الزام سازمان به محیط اختصاصی برسد. اگر اطلاعات مصرف هنوز کافی نباشد، میتوان ابتدا یک مرحله محدود برای بررسی ظرفیت تعریف کرد. تصمیم خوب، تصمیمی است که دلیل و فرضهایش قابل توضیح باشد و مسئول اجرای قدم بعدی را مشخص کند.
از پیشنهاد مبهم چه سؤال تکمیلی بپرسیم
در بازبینی پیشنهاد سرویس، مدیر مالی متوجه میشود عبارت «قابل توسعه» نوشته شده اما زمان و هزینه توسعه مشخص نیست. مدیر فناوری هم میبیند «پشتیبانی» ذکر شده، ولی معلوم نیست چه نوع درخواستهایی را پوشش میدهد. تیم تصمیم میگیرد این دو مورد را به سؤال مکتوب تبدیل کند. توضیح تکمیلی باید بخشی از پیشنهاد باشد تا بعداً دو طرف به برداشت متفاوتی استناد نکنند.
در پیشنهاد خرید نیز عبارت «آماده بهرهبرداری» وجود دارد. مدیرعامل میپرسد این عبارت شامل چه کاری است: راهاندازی تجهیزات، فراهم شدن دسترسی افراد یا تأیید نتیجه آزمون سازمان؟ هرکدام میتواند زمان و هزینه متفاوتی داشته باشد. تعریف روش تحویل، قبل از امضای توافق، امکان مقایسه منصفانه را بیشتر میکند و اختلاف پس از اجرا را کاهش میدهد.
موضوع دیگری که در جلسه مطرح میشود، مدت اعتبار فرضهاست. شاید برآورد مصرف برای سه ماه نخست مناسب باشد، اما با اضافه شدن یک واحد جدید تغییر کند. لازم است زمان بازبینی مشخص شود و پیشنهاد، نقطه تغییر هزینه را توضیح دهد. اگر برای قیمت یا ظرفیت اعتبار زمانی وجود دارد، همان محدودیت هم باید در تصمیم مدیریت دیده شود.
در پایان، مدیر مالی از تیم میخواهد موارد نامعلوم را با صفر پر نکنند. هزینهای که هنوز استعلام نشده، هزینه صفر نیست. شرایطی که درباره آن پاسخی دریافت نشده نیز به معنی نبود محدودیت نیست. جدول مقایسه میتواند یک ستون کوتاه برای «نیازمند پاسخ» داشته باشد. تصمیم نهایی زمانی گرفته شود که ابهامهای اثرگذار بر بودجه، تحویل و مسئولیت روشن شده باشند، حتی اگر جزئیات کماهمیتتر در ادامه تکمیل شوند.
بررسی گزینه متناسب با سازمان در راگا
راگا زیرساخت Private AI را با امکان بررسی دو مسیر دریافت سرویس و پیادهسازی اختصاصی مطرح میکند. برای سازمانی که میخواهد گزینه سرویس Multi-Tenant را ارزیابی کند، گفتوگو از نیاز اولیه، الزامات دسترسی، زمان شروع و نحوه مصرف آغاز میشود. اگر زیرساخت اختصاصی مناسبتر باشد، همان نیازها مبنای طراحی پروژه قرار میگیرند.
برای شروع این گفتوگو، یک شرح کوتاه از ظرفیت موردنیاز یا کاری که باید از نظر زیرساخت پشتیبانی شود کافی است. اطلاعات نامشخص را هم ذکر کنید تا در مرحله بررسی اندازهگیری شود. هدف جلسه، دریافت پیشنهادی است که با شرایط شما قابل مقایسه و قابل تصمیمگیری باشد.
مدیر مالی سازمان حالا سؤال دقیقتری دارد: «اگر با ظرفیت محدود شروع کنیم، چه چیزی را باید اندازه بگیریم تا زمان توسعه را بفهمیم؟» در ادامه این مجموعه، همین تصمیم مرحلهای را دنبال میکنیم؛ شروعی که اندازه آن با نیاز واقعی هماهنگ باشد و مسیر رشدش از ابتدا روشن شود.
چکلیست تصمیمگیری
- نیاز و مالک کسبوکاری مشخص باشد.
- نوع داده و محدودیت دسترسی ثبت شود.
- ظرفیت پایه و اوج مصرف جدا محاسبه شوند.
- مدل اختصاصی یا Multi‑Tenant با معیار مشترک مقایسه شود.
برای تصمیمگیری درباره Private AI
نیاز، ظرفیت، داده و مدل بهرهبرداری سازمان را پیش از خرید یا دریافت سرویس بررسی کنید.
سؤالات متداول
Private AI را از کجا شروع کنیم؟
از یک نیاز تأییدشده، مالک مشخص، نوع داده، الگوی مصرف و معیار موفقیت شروع کنید؛ نه از فهرست تجهیزات.
زیرساخت اختصاصی بهتر است یا سرویس Multi‑Tenant؟
پاسخ به حساسیت داده، زمان شروع، الگوی مصرف، توان بهرهبرداری و سطح کنترل موردنیاز بستگی دارد.
ظرفیت Private AI چگونه تعیین میشود؟
همزمانی، زمان پاسخ، حجم داده، دسترسپذیری، رشد و ظرفیت رزرو باید کنار هم سنجیده شوند.
منابع
[۱] تعریف زیرساخت بهعنوان سرویس در سند NIST SP ۸۰۰-۱۴۵ مشاهده منبع
[۲] برنامه خروج از خدمت در سند NIST SP ۸۰۰-۱۴۴ مشاهده منبع
مطالب مرتبط در سایت راگا
برای تکمیل این مسیر، راهنمای Private AI روی VCF و مقاله «تصمیم اولیه سازمان برای تأمین زیرساخت Private AI» را ببینید.