IT PROCUREMENT

تأمین تجهیزات باید ادامه طراحی باشد، نه یک خرید جدا از معماری

در پروژه‌های زیرساختی، اشتباه در مدل، پارت‌نامبر، Firmware، License یا ظرفیت می‌تواند بعداً به مشکل Compatibility، کمبود توسعه‌پذیری یا هزینه اضافه تبدیل شود. تأمین درست یعنی BOM قبل از خرید از نظر فنی کنترل شود و اقلام با معماری واقعی پروژه هماهنگ باشند.

ثبت درخواست تأمین مشاهده طراحی معماری

قبل از سفارش

آیا BOM واقعاً با پروژه سازگار است؟

Part Number درست انتخاب شده؟
Compatibility بررسی شده؟
Firmware و License هماهنگ‌اند؟
ظرفیت توسعه دیده شده؟
کالا جایگزین قابل قبول دارد؟
زمان تحویل با برنامه پروژه هماهنگ است؟

PROJECT-BASED PROCUREMENT

در پروژه سازمانی، ارزان‌ترین انتخاب همیشه کم‌هزینه‌ترین انتخاب نیست

اگر تجهیزی با معماری، Lifecycle یا برنامه توسعه هماهنگ نباشد، هزینه اصلی ممکن است بعد از خرید ظاهر شود. برای همین تأمین باید با Design، BOM و مسیر اجرایی پروژه ارتباط مستقیم داشته باشد.

حوزه‌های تأمین

تأمین تجهیزات زیرساختی بر اساس نیاز پروژه

Server و Compute

سرور، CPU، RAM، NIC، HBA و سایر اجزای پردازشی بر اساس Sizing و نیاز معماری.

Storage

Storage، Disk، SSD و اجزای توسعه ظرفیت با توجه به Performance، Growth و Compatibility.

Network

Switch، Router، Transceiver، Module، NIC و تجهیزات ارتباطی متناسب با Topology و Bandwidth.

Security

Firewall، WAF و تجهیزات امنیتی همراه با Subscription یا License موردنیاز پروژه.

Backup Infrastructure

Repository، Storage و تجهیزات موردنیاز برای طراحی Backup، Immutability و Recovery.

GPU و AI Infrastructure

Compute و GPU برای پروژه‌های Private AI بر اساس Capacity و معماری زیرساخت، نه صرفاً انتخاب یک کارت پردازشی.

BOM REVIEW

قبل از تأمین، BOM باید یک بار از نگاه اجرا دیده شود

BOM ممکن است روی کاغذ کامل باشد اما در اجرا کمبود Port، Cable، License، Module یا Compatibility خودش را نشان دهد. مرور فنی قبل از سفارش کمک می‌کند این فاصله زودتر مشخص شود.

در بازبینی BOM به این موارد نگاه می‌کنیم

Part Number و Configuration
Compatibility بین اجزا
Firmware و Software Requirement
Port، Cable و Transceiver
License و Subscription
مسیر توسعه Capacity

Lifecycle مهم‌تر از موجودی لحظه‌ای

کالایی که امروز موجود است، لزوماً انتخاب مناسبی برای چند سال آینده نیست

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

پرسش‌های Lifecycle

آیا نسل محصول مناسب است؟
مسیر توسعه دارد؟
قطعات قابل تأمین‌اند؟
Firmware و Software موردنیاز پشتیبانی می‌شوند؟
با معماری آینده سازمان هماهنگ است؟

جایگزین فنی، نه جایگزین اسمی

اگر یک مدل قابل تأمین نیست، جایگزین باید دوباره با Requirement سنجیده شود

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

فرآیند تأمین