در رویداد Private AI راگا، پاسخ کدام تصمیم سازمانی را می‌گیریم؟

اولویت رویداد، مسیر دریافت سرویس است؛ چون بسیاری از سازمان‌ها هنوز مصرف دقیق خود را نمی‌دانند، بودجه خرید کامل ندارند یا می‌خواهند سریع‌تر و مرحله‌ای شروع کنند. مسیر اختصاصی نیز برای سازمان‌هایی بررسی می‌شود که الزام کنترل، محل داده یا مصرف پایدار دارند. هدف، انتخاب از روی شرایط واقعی است.

در این راهنما، موضوع از چند زاویه بررسی می‌شود: تصمیم اول: مسئله سازمان چیست؟، تصمیم دوم: سرویس یا زیرساخت اختصاصی؟، تصمیم سوم: Multi-Tenant برای ما قابل قبول است؟. هدف این است که مخاطب پس از مطالعه، معیارهای تصمیم‌گیری و اقدام بعدی را روشن‌تر ببیند.

تصمیم اول: مسئله سازمان چیست؟

بسیاری از درخواست‌ها با جمله «برای AI زیرساخت می‌خواهیم» آغاز می‌شوند. این جمله هنوز برای طراحی یا قیمت‌گذاری کافی نیست. چه واحدی قرار است استفاده کند؟ چه داده‌ای وارد می‌شود؟ زمان شروع چه موقع است؟ استفاده دائمی است یا دوره‌ای؟ چه نتیجه‌ای باید در یک دوره محدود دیده شود؟

در رویداد، شرکت‌کننده با یک چارچوب ساده نیاز را صورت‌بندی می‌کند. هدف این نیست که همه جزئیات فنی همان‌جا نهایی شوند. باید مشخص شود کدام اطلاعات برای تصمیم بعدی لازم است و مسئول جمع‌آوری آن در سازمان چه کسی است. نیاز روشن، از پیشنهادهای بزرگ و مبهم جلوگیری می‌کند.

تصمیم دوم: سرویس یا زیرساخت اختصاصی؟

دریافت سرویس می‌تواند زمان شروع و سرمایه‌گذاری اولیه را کاهش دهد و ظرفیت را نزدیک‌تر به نیاز فراهم کند. زیرساخت اختصاصی اختیار بیشتری بر محل، منابع و تغییرات می‌دهد. هر مسیر مسئولیت و هزینه متفاوتی دارد. انتخاب فقط با مقایسه قیمت انجام نمی‌شود.

در رویداد، شاخص‌های تصمیم کنار هم قرار می‌گیرند: حساسیت داده، ثبات مصرف، زمان شروع، توان تیم بهره‌برداری، نیاز به منابع تضمین‌شده و افق بودجه. ممکن است پاسخ یک سازمان ترکیبی باشد؛ بخشی از نیاز به سرویس و بخشی به محیط اختصاصی برود.

تصمیم سوم: Multi-Tenant برای ما قابل قبول است؟

Multi-Tenant یعنی چند سازمان از یک بستر خدماتی استفاده می‌کنند، در حالی که محیط، هویت و دسترسی هرکدام با کنترل‌های مشخص تفکیک می‌شود. پرسش اصلی این نیست که منابع مشترک‌اند یا نه؛ باید بدانیم مرزها چگونه طراحی، آزمون و گزارش می‌شوند.

در رویداد درباره پرسش‌هایی صحبت می‌شود که مدیران باید از ارائه‌دهنده بپرسند: داده کجا قرار می‌گیرد؟ چه کسی دسترسی مدیریتی دارد؟ جداسازی در هویت، شبکه و Storage چگونه انجام می‌شود؟ مصرف و رخداد چگونه گزارش می‌شوند؟ پاسخ باید به شواهد و تعهد قابل سنجش متصل باشد.

تصمیم چهارم: از چه ظرفیتی شروع کنیم؟

خرید بر اساس تعداد کل کارکنان یا بزرگ‌ترین احتمال آینده معمولاً برآورد قابل اتکایی نمی‌سازد. ظرفیت به نوع استفاده، تعداد هم‌زمان، مدت فعالیت، حجم داده و زمان قابل قبول وابسته است. در شروع، بخشی از این اطلاعات هنوز نامعلوم است؛ باید آن را به فرض قابل آزمون تبدیل کرد.

در رویداد، مدل ظرفیت پایه، اوج و رشد توضیح داده می‌شود. سازمان می‌تواند از دامنه محدود آغاز و شواهد مصرف را جمع کند. افزایش ظرفیت باید به محرک مشخص متصل باشد. این روش از خرید بیش از نیاز یا شروع با ظرفیت ناکافی جلوگیری می‌کند.

تصمیم پنجم: هزینه واقعی کدام مسیر چقدر است؟

قیمت تجهیزات با هزینه داشتن زیرساخت متفاوت است. برق، سرمایش، شبکه، Storage، نرم‌افزار، پشتیبانی، نیروی انسانی، قطعه، بکاپ و توسعه در طول زمان هزینه می‌سازند. در سرویس نیز مبلغ پایه، مصرف اوج، تعهد ظرفیت، انتقال داده و شرایط خروج باید روشن باشند.

در بخش اقتصادی رویداد، دامنه و دوره مقایسه یکسان می‌شود. هدف اعلام یک قیمت عمومی نیست؛ شرکت‌کننده می‌آموزد چه ورودی‌هایی برای برآورد واقعی سازمانش نیاز دارد و چگونه فرض‌ها را در سه سناریوی مصرف بسنجد.

تصمیم ششم: داده و دسترسی چگونه کنترل می‌شوند؟

حاکمیت داده از نام Private AI به دست نمی‌آید. سازمان باید طبقه‌بندی داده، مسیر انتقال، محل نگهداری، نسخه‌های پشتیبان، دوره حذف و نقش‌های دسترسی را مشخص کند. ارائه‌دهنده نیز باید مرز مسئولیت و کنترل‌های زیرساخت را توضیح دهد.

در رویداد، این موضوع به زبان مدیریتی مطرح می‌شود: چه کسی می‌تواند چه کاری انجام دهد و چه شاهدی برای آن وجود دارد؟ مدیر فناوری می‌تواند پس از جلسه، پرسش‌ها را با تیم امنیت و حقوقی تکمیل کند. هدف، ساختن فهرستی قابل استفاده برای ارزیابی سرویس است.

تصمیم هفتم: چه سطح خدمتی نیاز داریم؟

همه کاربردها به دسترس‌پذیری و زمان پاسخ یکسان نیاز ندارند. یک فعالیت آزمایشی می‌تواند توقف کوتاه را تحمل کند، اما فرایند متصل به عملیات روزانه شرایط دیگری دارد. سطح خدمت باید با اثر کسب‌وکاری هماهنگ باشد؛ بالاترین سطح برای همه، هزینه را بدون ارزش روشن افزایش می‌دهد.

شرکت‌کنندگان یاد می‌گیرند زمان پاسخ، زمان رفع، ظرفیت رزروشده و زمان توسعه را از هم جدا کنند. معیار پذیرش برای محیط و مسیر پشتیبانی نوشته می‌شود. این زبان مشترک گفت‌وگو با ارائه‌دهنده را دقیق‌تر می‌کند.

تصمیم هشتم: اگر مصرف تغییر کرد چه می‌کنیم؟

مصرف AI در بسیاری از سازمان‌ها در آغاز ثابت نیست. ممکن است یک واحد آزمایش را شروع کند، استفاده کاهش یابد یا چند واحد هم‌زمان وارد شوند. مدل تأمین باید امکان بازبینی داشته باشد. خرید ثابت، سرویس قابل تغییر و مدل ترکیبی هرکدام واکنش متفاوتی دارند.

در رویداد درباره گزارش مصرف، آستانه توسعه و بازه تصمیم صحبت می‌شود. مدیر مالی باید پیش از افزایش هزینه اطلاع داشته باشد و مدیر فناوری باید کمبود ظرفیت را زود تشخیص دهد. ظرفیت به یک گفت‌وگوی دوره‌ای تبدیل می‌شود، نه بحرانی در روز شلوغ.

تصمیم نهم: تیم داخلی چه مسئولیتی دارد؟

دریافت سرویس همه مسئولیت را منتقل نمی‌کند. سازمان هنوز مالک داده، کاربران، نیاز و بخشی از امنیت است. در زیرساخت اختصاصی، دامنه مسئولیت بیشتر می‌شود و نگهداری روزانه، Patch، ظرفیت و قطعه نیز باید پوشش داده شوند. نقش‌ها باید پیش از شروع روشن باشند.

رویداد به مدیران کمک می‌کند RACI ساده‌ای برای تصمیم بسازند: چه کسی نیاز را تأیید می‌کند، چه کسی دسترسی را مدیریت می‌کند، چه کسی مصرف را می‌بیند و چه کسی در رخداد تصمیم می‌گیرد. ابهام نقش، حتی با بهترین تجهیزات، به تأخیر و ریسک منجر می‌شود.

تصمیم دهم: دمو چه چیزی را باید ثابت کند؟

دمو نباید فقط نمایش روشن بودن زیرساخت باشد. باید یک سؤال تصمیمی را پاسخ دهد: زمان آماده شدن محیط چقدر است؟ جداسازی چگونه دیده می‌شود؟ گزارش مصرف چه اطلاعاتی می‌دهد؟ افزایش ظرفیت چه فرایندی دارد؟ سناریوی نماینده باید پیش از دمو انتخاب شود.

شرکت‌کننده می‌تواند شرایط سازمانش را با خود بیاورد و بداند برای دمو یا Assessment بعدی چه داده‌ای لازم است. معیار موفقیت و موارد نامعلوم ثبت می‌شوند. دمو بخشی از فرایند تصمیم‌سازی است، نه پایان آن.

چه چیزهایی را با خود به رویداد بیاوریم؟

یک شرح یک‌صفحه‌ای از نیاز کافی است: واحد متقاضی، نوع داده، تعداد استفاده‌کنندگان یا فعالیت هم‌زمان، زمان شروع، محدودیت محل و دسترسی و سقف تقریبی بودجه. اگر عدد دقیق وجود ندارد، بازه و موارد نامعلوم نوشته شوند. همین اطلاعات گفت‌وگو را از کلی‌گویی دور می‌کند.

همچنین بهتر است یک نماینده از مدیریت و یک نماینده از فناوری حضور داشته باشند. تصمیم Private AI فقط فنی یا مالی نیست. حضور هر دو نگاه کمک می‌کند ارزش، ریسک و امکان اجرا هم‌زمان بررسی شوند. امنیت و داده نیز می‌توانند پرسش‌های خود را پیش از رویداد ارسال کنند.

خروجی موردانتظار برای مدیرعامل

مدیرعامل باید پس از رویداد بتواند یکی از چند تصمیم را بگیرد: ادامه بررسی سرویس Multi-Tenant، درخواست Assessment زیرساخت اختصاصی، اجرای Pilot محدود یا توقف موقت تا تکمیل اطلاعات. «جالب بود» خروجی تصمیمی نیست. گام بعدی، مسئول و زمان باید روشن باشند.

یک برگه تصمیم می‌تواند معیارها، گزینه ترجیحی، اطلاعات ناقص و ریسک‌های پذیرفته‌شده را ثبت کند. این برگه پایه جلسه داخلی بعدی می‌شود و اجازه می‌دهد هیجان رویداد به اقدام بی‌برنامه تبدیل نشود.

خروجی موردانتظار برای مدیر فناوری

مدیر فناوری باید فهرست اطلاعات لازم برای طراحی یا سرویس را داشته باشد: مسیر داده، هویت، شبکه، Storage، ظرفیت، بکاپ، مانیتورینگ و پشتیبانی. همه پاسخ‌ها در رویداد نهایی نمی‌شوند، اما ترتیب بررسی روشن می‌شود. او می‌تواند تیم‌های داخلی را برای تکمیل داده‌ها هماهنگ کند.

همچنین باید بداند چه سؤال‌هایی از راگا بپرسد و چه شاهدی بخواهد. دامنه دمو یا Assessment بعدی با همین اطلاعات تعریف می‌شود. هدف، کوتاه کردن فاصله میان علاقه مدیریتی و تصمیم فنی قابل اجراست.

نقش راگا در رویداد

راگا تجربه طراحی و ارائه زیرساخت را در قالب سناریوهای سازمانی مطرح می‌کند. مسیر اصلی، دریافت زیرساخت Private AI به‌صورت سرویس Multi-Tenant است؛ مسیری که می‌تواند شروع مرحله‌ای، گزارش مصرف و توسعه متناسب با نیاز را ممکن کند. مسیر دوم، طراحی و پیاده‌سازی زیرساخت اختصاصی برای الزام‌های مشخص است.

گفت‌وگو بر زیرساخت، ظرفیت، امنیت، Storage، شبکه، بکاپ و عملیات متمرکز می‌ماند. هر سازمان می‌تواند نیاز و محدودیت خود را مطرح کند تا گام بعدی متناسب پیشنهاد شود. رویداد نقطه آغاز Assessment و دموهای هدفمند است.

ادامه روایت سازمان

مدیرعامل تصمیم می‌گیرد همراه مدیر فناوری در رویداد حاضر شود. آن‌ها یک برگه کوتاه آماده می‌کنند: دو واحد متقاضی، داده با حساسیت متفاوت، مصرف نامعلوم و بودجه مرحله‌ای. پنج سؤال درباره Multi-Tenant و سه معیار برای دمو نیز نوشته می‌شود. هدفشان خرید در همان روز نیست؛ می‌خواهند با یک مسیر تصمیم روشن بازگردند.

اگر سازمان شما نیز میان خرید و دریافت سرویس، ظرفیت و هزینه یا کنترل و سرعت شروع در حال تصمیم است، این رویداد برای همان گفت‌وگو طراحی شده است. جزئیات دعوت و مسیر اعلام علاقه‌مندی در محتوای بعدی کمپین منتشر می‌شود. سناریوی واقعی سازمان، بهترین نقطه شروع گفت‌وگو خواهد بود.

پرسش‌هایی که پیش از رویداد برای راگا بفرستیم

برای استفاده بهتر از زمان، سازمان می‌تواند سه پرسش اصلی خود را پیشاپیش ارسال کند. پرسش‌ها ممکن است درباره جداسازی در Multi-Tenant، ظرفیت قابل رزرو، محل داده، مدل پشتیبانی یا هزینه توسعه باشند. تیم رویداد می‌تواند موضوعات مشترک را در بخش عمومی پاسخ دهد و موارد خاص را برای گفت‌وگوی بعدی نگه دارد.

اطلاعات محرمانه لازم نیست. شرح مسئله و محدودیت کافی است. برای مثال: «مصرف ما فقط در ده روز پایان ماه افزایش می‌یابد؛ چه مدلی برای ظرفیت مناسب است؟» این سؤال امکان توضیح سناریوی پایه و اوج را می‌دهد. پرسش دقیق، پاسخ کاربردی‌تری تولید می‌کند.

چه تصمیمی در خود رویداد گرفته نمی‌شود؟

بدون Assessment، اندازه دقیق زیرساخت اختصاصی یا قیمت نهایی سرویس تعیین نمی‌شود. معماری امنیتی نیز با چند اسلاید تأیید نمی‌گردد. رویداد برای روشن کردن گزینه‌ها، معیارها و گام بعدی است. این مرزبندی از وعده عجولانه و برداشت نادرست جلوگیری می‌کند.

اگر سازمان پس از جلسه مسیر سرویس را ترجیح دهد، اطلاعات ظرفیت و دسترسی تکمیل می‌شود. اگر مسیر اختصاصی مناسب باشد، ارزیابی محل، شبکه و Storage آغاز می‌گردد. اگر ابهام Use Case باقی مانده باشد، Pilot محدود پیشنهاد می‌شود. هر سه خروجی معتبرند.

تجربه رویداد را به تصمیم داخلی منتقل کنیم

پس از بازگشت، نمایندگان سازمان بهتر است یک جلسه کوتاه با مدیران مرتبط برگزار کنند. معیارهای آموخته‌شده، گزینه ترجیحی و موارد نامعلوم مرور شوند. اگر تنها فایل ارائه میان افراد پخش شود، تفاوت برداشت‌ها باقی می‌ماند. یک برگه تصمیم مشترک نتیجه را حفظ می‌کند.

در این جلسه می‌توان مالک گام بعدی و زمان آن را تعیین کرد. درخواست Assessment، آماده‌سازی داده برای دمو یا بررسی بودجه هرکدام مسئول متفاوتی دارند. رویداد زمانی ارزش کامل پیدا می‌کند که گفت‌وگوی آن به برنامه داخلی متصل شود.

برنامه‌ریزی برای حضور هدفمند

پیش از رویداد، مدیرعامل می‌تواند یک نتیجه موردانتظار بنویسد و مدیر فناوری سه محدودیت اصلی را اضافه کند. پس از هر بخش، آن‌ها بررسی می‌کنند آیا اطلاعات تازه‌ای برای همان تصمیم به دست آمده است. این روش حضور را از شنیدن مجموعه‌ای از مطالب جدا می‌کند و تمرکز را بر مسئله سازمان نگه می‌دارد.

اگر چند سازمان مسئله مشابهی داشته باشند، گفت‌وگوی جمعی نیز ارزشمند می‌شود؛ بدون افشای اطلاعات حساس می‌توان معیارها و تجربه تصمیم را مقایسه کرد. تفاوت شرایط یادآوری می‌کند که یک پاسخ برای همه وجود ندارد. ساختار رویداد باید امکان پرسش مدیریتی و گفت‌وگوی فنی محدود را کنار هم فراهم کند.

معیار موفقیت خود رویداد

موفقیت رویداد فقط با تعداد حاضران سنجیده نمی‌شود. باید دید چند سازمان مسئله مشخص خود را صورت‌بندی کرده‌اند، چه تعداد گام بعدی متناسب دارند و آیا مدیران توانسته‌اند مسیر سرویس و اختصاصی را با معیار مشترک مقایسه کنند. کیفیت پرسش‌ها و وضوح اقدام بعدی از حجم ارائه مهم‌تر است.

راگا می‌تواند پس از رویداد، نیازهای پرتکرار را بدون اشاره به اطلاعات محرمانه جمع‌بندی کند. این بازخورد به تکمیل دمو، Assessment و محتوای بعدی کمک می‌کند. شرکت‌کنندگان نیز باید بدانند چه پاسخی در جلسه عمومی داده شده و کدام موضوع نیازمند بررسی اختصاصی است.

پیوند رویداد با برنامه پنجاه‌روزه کمپین

محتواهای پیش از رویداد برای ساخت زبان مشترک منتشر می‌شوند: ظرفیت، Multi-Tenant، اعتماد، هزینه و زیرساخت اختصاصی. رویداد نقطه جمع شدن این مسیر است. مخاطب پیش از حضور با پرسش‌ها آشناست و زمان جلسه برای توضیح تعریف‌های اولیه مصرف نمی‌شود.

پس از رویداد، محتوا باید به پرسش‌های واقعی و گام‌های بعدی پاسخ دهد. دمو، برآورد ظرفیت و تجربه تصمیم‌گیری هرکدام می‌توانند ادامه روایت باشند. کمپین با برگزاری جلسه تمام نمی‌شود؛ باید علاقه را به ارزیابی و تصمیم عملی متصل کند.

چک‌لیست تصمیم‌گیری

• نیاز و مالک کسب‌وکاری مشخص باشد.
• نوع داده و محدودیت دسترسی ثبت شود.
• ظرفیت پایه و اوج مصرف جدا محاسبه شوند.
• مدل اختصاصی یا Multi‑Tenant با معیار مشترک مقایسه شود.

سؤالات متداول

Private AI را از کجا شروع کنیم؟

از یک نیاز تأییدشده، مالک مشخص، نوع داده، الگوی مصرف و معیار موفقیت شروع کنید؛ نه از فهرست تجهیزات.

زیرساخت اختصاصی بهتر است یا سرویس Multi‑Tenant؟

پاسخ به حساسیت داده، زمان شروع، الگوی مصرف، توان بهره‌برداری و سطح کنترل موردنیاز بستگی دارد.

ظرفیت Private AI چگونه تعیین می‌شود؟

هم‌زمانی، زمان پاسخ، حجم داده، دسترس‌پذیری، رشد و ظرفیت رزرو باید کنار هم سنجیده شوند.

منابع

[۱] Microsoft Learn — نمای کلی معماری Multi-Tenant و ملاحظات اشتراک و جداسازی مشاهده منبع

[۲] NIST SP ۸۰۰-۱۴۵ — تعریف ویژگی‌ها و مدل‌های سرویس زیرساختی مشاهده منبع

مطالب مرتبط در سایت راگا

برای تکمیل این مسیر، راهنمای Private AI روی VCF و مقاله «قیمت خرید با هزینه داشتن زیرساخت Private AI چه تفاوتی دارد؟» را ببینید.