درخواست خرید تجهیزات معمولاً با تعداد دستگاه و بودجه شروع میشود؛ اما این اطلاعات برای انتخاب مناسب کافی نیست. اگر کاربران از کندی نرمافزار شکایت دارند، ابتدا باید مشخص شود مشکل به رایانه، ارتباط شبکه، برنامه یا منابع مشترک مربوط است. خرید دستگاه جدید، بدون روشنشدن علت و نیاز واقعی، ممکن است مسئله را باقی بگذارد.
نیازسنجی زیرساخت IT فرایند شناخت وضعیت موجود، تعیین نیازهای عملیاتی و تعریف نتیجه قابل سنجش پیش از انتخاب راهکار و تجهیزات است. خروجی آن باید نشان دهد چه چیزی باید تغییر کند، چه چیزی قابل استفاده است و موفقیت تغییر چگونه بررسی میشود.
در این راهنما، مراحل تهیه همین خروجی را مرور میکنیم. اگر به شناخت اجزای زیرساخت نیاز دارید، ابتدا مقاله زیرساخت فناوری اطلاعات سازمان چیست؟ را بخوانید.
1- مسئله و محدوده پروژه را دقیق بنویسید
عبارتهایی مانند «سیستمها قدیمیاند» یا «به تجهیزات قویتر نیاز داریم» برای شروع گفتوگو مناسباند، اما هنوز مبنای تصمیم نیستند. مسئله باید به یک کار مشخص و اثر آن بر سازمان متصل شود: کدام عملیات مختل میشود، چه کسانی درگیرند و مشکل چه زمانی رخ میدهد؟
مشاهده را از تشخیص اولیه جدا کنید
«تهیه گزارش مالی طول میکشد» یک مشاهده است؛ «حافظه رایانه کم است» فرضیهای درباره علت آن است. فرضیه را تا زمان بررسی، نتیجه قطعی ننویسید. زمان رخداد، پیام خطا، کاربران درگیر و وضعیت منابع هنگام بروز مشکل را ثبت کنید.
برای هر مسئله، یک مسئول کسبوکار هم مشخص کنید؛ کسی که بتواند اثر اختلال و اهمیت رفع آن را توضیح دهد. اولویت فنی باید با اهمیت خدمت برای سازمان ارتباط داشته باشد.
محدوده این مرحله را مشخص کنید
نام واحدها، گروه کاربران، محل استقرار و خدمات مشمول پروژه را بنویسید. برای مثال، نوسازی تجهیزات واحد مالی الزاماً شامل تغییر سامانه حسابداری یا ارتباط تمام شعب نیست. وابستگی به این بخشها باید بررسی شود، ولی تغییر آنها نیازمند تصمیم مشخص است.
این تفکیک کمک میکند پیشنهادهای دریافتی درباره یک دامنه مشترک باشند و هزینههای مربوط به درخواستهای جدید از ابتدای پروژه قابل تشخیص شوند.
2- وضعیت موجود را با مدرک ثبت کنید
وضعیت موجود یا As-Is، تصویر محیطی است که امروز واقعاً از آن استفاده میشود. فهرست خرید سالهای گذشته نقطه شروع مناسبی است، اما جای بررسی داراییهای فعال و نحوه استفاده از آنها را نمیگیرد.
تجهیزات و نرمافزارهای فعال
برای تجهیزات، شناسه دارایی، کاربر یا مالک، محل، پیکربندی، وضعیت پشتیبانی و خرابیهای ثبتشده را جمعآوری کنید. فهرست باید دستگاههای دورکار و منابع خارج از دفتر را نیز در محدوده پروژه پوشش دهد. کنترل اول CIS درباره داراییهای سازمانی بر شناسایی و مدیریت داراییهای متصل در محیطهای مختلف تأکید دارد.
در فهرست نرمافزارها، نام، نسخه، محل اجرا، وضعیت مجوز و پشتیبانی را بنویسید. سیستمعامل، برنامههای اصلی و ابزارهایی که فقط یک واحد استفاده میکند، همگی میتوانند بر انتخاب تجهیزات اثر بگذارند. کنترل دوم CIS درباره داراییهای نرمافزاری نیز شناسایی و مدیریت نرمافزارهای مجاز و غیرمجاز را مطرح میکند.
این دو کنترل، منابع بخش موجودی داراییها هستند؛ چکلیست این مقاله یک قالب نیازسنجی پیشنهادی است و ادعای انطباق کامل سازمان با CIS ندارد.
وابستگیها و قابلیت استفاده مجدد
مشخص کنید برنامه به کدام سرور، سرویس هویت، مسیر ارتباط، چاپگر، اسکنر یا وسیله تخصصی وابسته است. مدلی که از نظر پردازنده مناسب به نظر میرسد، ممکن است درگاه یا سازگاری لازم برای وسیله فعلی سازمان را نداشته باشد.
تجهیزات موجود را برای حفظ، ارتقا یا جایگزینی بررسی کنید. وضعیت پشتیبانی، سلامت، سازگاری و هزینه نگهداری باید در این تصمیم دیده شوند. قدیمیبودن بهتنهایی حکم تعویض نیست و روشنشدن دستگاه نیز برای تأیید ادامه استفاده کافی نیست.
3- نیاز کاربران و شرایط اجرای کار را استخراج کنید
تعداد کارکنان را به گروههای کاری معنادار تبدیل کنید. برای هر گروه، برنامههای موردنیاز، تعداد کاربران همزمان، محل کار، نمایشگرها و تجهیزات جانبی را بنویسید. بار کاری یا Workload یعنی نوع و حجم عملیاتی که دستگاه یا سامانه باید انجام دهد.
برای نمونه، کاربری که فرم ثبت میکند با فردی که فایلهای مهندسی بزرگ را پردازش میکند نیاز یکسانی ندارد. حتی در یک واحد، بعضی کاربران ممکن است استثنا باشند؛ این استثناها را همراه با دلیل ثبت کنید.
نیاز فعلی و رشد پیشبینیشده را جدا بنویسید. افزایش احتمالی تعداد کاربران، داده یا شعب باید با برنامه سازمان و بازه زمانی آن همراه باشد؛ عبارت کلی «برای آینده هم مناسب باشد» مشخصات قابل ارزیابی ایجاد نمیکند.
شرایط محیط را نیز ثبت کنید: فضای میز، محل نصب، برق، تهویه، گردوغبار و امکان دسترسی برای تعمیر. در کنار آن، روشن کنید داده حساس کجا نگهداری میشود، چه کسانی مجاز به دسترسیاند و هنگام قطع ارتباط کدام کار باید ادامه یابد. قابلیت ادامه کار آفلاین باید با نرمافزار و معماری پیشنهادی تطبیق داده شود.
4- نتیجه مطلوب و معیار پذیرش را تعریف کنید
وضعیت هدف یا To-Be توضیح میدهد محیط پس از تغییر باید چه قابلیتی داشته باشد. این توصیف باید به کار روزانه مربوط باشد: اجرای نرمافزار مشخص، اتصال تجهیزات جانبی، مدیریت حسابها یا بازیابی کار پس از اختلال.
برای هر نیاز، روش آزمون، مسئول تأیید و شرط پذیرش تعیین کنید. اگر مسئله سرعت است، ابتدا زمان فعلی عملیات را در شرایط معلوم اندازه بگیرید؛ سپس هدف را با مسئول آن فرایند توافق کنید. مقایسه قبل و بعد باید با داده و بار کاری قابل مقایسه انجام شود.
آزمون محدود یا پایلوت را با کاربران نماینده، نرمافزار واقعی و تجهیزات جانبی مرتبط طراحی کنید. آزمایش فقط روی یک دستگاه خالی، تجربه کار در محیط سازمان را نشان نمیدهد. پیش از گسترش تغییر نیز مسیر بازگشت در صورت نتیجه نامطلوب مشخص باشد.
5- بودجه، زمان اجرا و مسئولیت پشتیبانی را روشن کنید
بودجه را به خرید دستگاه محدود نکنید. نصب، انتقال داده، مجوز نرمافزار، آموزش، پشتیبانی و توقف احتمالی کار نیز باید در برآورد دیده شوند. این نگاه به هزینه کل مالکیت یا TCO کمک میکند گزینهها را در یک دوره و با دامنه یکسان مقایسه کنید.
زمان تحویل تجهیزات با زمان آمادهبهکاری کاربران یکسان نیست. مسئول نصب، امکان اجرای مرحلهای، ساعت مجاز تغییر و نیاز به دستگاه جایگزین را مشخص کنید. از تأمینکننده نیز درباره دامنه خدمات، شرایط ضمانت و مسیر رسیدگی به خرابی توضیح مکتوب بخواهید.
اگر بخشی از اطلاعات هنوز معلوم نیست، آن را با برچسب «نیازمند بررسی» ثبت کنید و مسئول و مهلت تعیین کنید. تبدیل اطلاعات نامعلوم به فرض قطعی، برآورد و انتخاب بعدی را آسیبپذیر میکند.
چکلیست جلسه نیازسنجی زیرساخت IT
جدول زیر را میتوانید برای جلسه داخلی تکمیل کنید. پاسخها باید مشخص و قابل پیگیری باشند؛ برای هر مدرک، تاریخ و محل نگهداری آن را نیز ثبت کنید.
| سؤال کلیدی | پاسخ سازمان | مدرک موردنیاز | مسئول پیشنهادی |
|---|---|---|---|
|
چه مسئلهای باید حل شود؟
|
خدمت، اختلال و اثر آن: … | نمونه رخداد یا گزارش درخواستها | مالک فرایند |
|
چه کسانی در محدودهاند؟
|
واحد، محل و کاربران همزمان: … | فهرست گروههای کاری | مدیر واحد و IT |
|
اکنون چه داراییهایی فعالاند؟
|
تجهیزات و وضعیت آنها: … | فهرست دارایی بهروز | IT |
|
کدام برنامهها و لوازم ضروریاند؟
|
نسخه، محل اجرا و وابستگیها: … | مستندات و آزمون سازگاری | IT و کاربران منتخب |
|
چه محدودیتهایی وجود دارد؟
|
ارتباط، دسترسی و محیط: … | نقشه ارتباط و الزامات مصوب | زیرساخت، امنیت و تأسیسات |
|
چه منابعی قابل حفاظتاند؟
|
حفظ، ارتقا یا جایگزینی: … | ارزیابی سلامت و پشتیبانی | IT و پشتیبانی |
|
سقف هزینه و زمان پروژه چیست؟
|
بودجه، مهلت و زمان مجاز تغییر: … | برآورد و تقویم مصوب | مالی، خرید و عملیات |
|
نتیجه چگونه تأیید میشود؟
|
آزمون، شرط پذیرش و مسئول: … | خط مبنا و برنامه پایلوت | IT و مالک فرایند |
نمونه تکمیلشده؛ نوسازی واحد مالی
فرض کنید واحد مالی یک سازمان ۲۴ کاربر دارد و هنگام تهیه گزارش پایان ماه با کندی مواجه میشود. این سناریو فرضی است و نتیجه پروژه واقعی بهین تکنولوژی نیست.
در صورتمسئله اولیه مینویسیم: «کندی گزارشگیری در ساعتهای پایانی ماه مشاهده شده؛ علت هنوز تأیید نشده است.» سپس نسخه برنامه، تعداد کاربران همزمان، زمان تولید گزارش و وضعیت منابع رایانه، سرور و ارتباط ثبت میشود.
نیازهای ضروری این واحد شامل اجرای نسخه مورد تأیید نرمافزار مالی، کارکرد چاپگر فعلی و دسترسی متناسب با نقش کاربران است. تصمیم درباره حفظ یا تعویض رایانهها به نتیجه بررسی و آزمون نمونه وابسته میماند.
برای پذیرش، مدیر مالی باید صحت خروجی و IT باید عملکرد و سازگاری را تأیید کند. هدف زمانی گزارش پس از ثبت خط مبنا تعیین میشود. این صورتمسئله به تیم خرید کمک میکند پیشنهادهایی با شرایط مشترک دریافت کند و علت انتخاب نهایی را توضیح دهد.
از چکلیست به انتخاب راهکار و تجهیزات
خروجی جلسه را به یک سند کوتاه شامل مسئله، محدوده، داراییهای قابل حفظ، نیازهای ضروری، محدودیتها و معیار پذیرش تبدیل کنید. همین سند، ورودی طراحی و دریافت پیشنهاد فنی خواهد بود.
در نوسازی تجهیزات کاربران، راهکار Enterprise Computing بهین تکنولوژی نیز ارزیابی نقش کاربران، بار کاری، مدل استقرار و چرخه عمر را مبنای انتخاب قرار میدهد. پس از روشنشدن این نیازها، میتوان گزینههایی مانند مینیکامپیوترهای UNIVO یا آلاینوان را متناسب با شرایط هر گروه بررسی کرد.
برای گفتوگو درباره نوسازی تجهیزات سازمان، خلاصه نیازها و تعداد کاربران را از طریق ارتباط با کارشناسان بهین تکنولوژی مطرح کنید. اطلاعات اولیه کمک میکند گفتوگو از مسئله مشخص سازمان شروع شود.
پرسشهای متداول درباره نیازسنجی زیرساخت IT
چه کسانی باید در جلسه نیازسنجی حضور داشته باشند؟
نماینده IT و مالک فرایند کاری، هسته اصلی جلسهاند. خرید و مالی درباره بودجه و تأمین مشارکت میکنند؛ در مسائل مرتبط، حضور امنیت، پشتیبانی یا تأسیسات نیز لازم است. جلسه میتواند مرحلهای برگزار شود.
برای سازمان کوچک هم نیازسنجی لازم است؟
بله؛ عمق بررسی باید متناسب با اندازه و حساسیت کار باشد. برای خرید محدود، ثبت برنامهها، تجهیزات جانبی، محدودیتها و روش پذیرش میتواند کوتاه باشد؛ پیچیدگی وابستگیها دامنه بررسی را افزایش میدهد.
برای سازمان کوچک هم نیازسنجی لازم است؟
بله؛ عمق بررسی باید متناسب با اندازه و حساسیت کار باشد. برای خرید محدود، ثبت برنامهها، تجهیزات جانبی، محدودیتها و روش پذیرش میتواند کوتاه باشد؛ پیچیدگی وابستگیها دامنه بررسی را افزایش میدهد.
برای سازمان کوچک هم نیازسنجی لازم است؟
خیر. نتیجه ممکن است اصلاح تنظیمات، رفع مشکل نرمافزار، ارتقای بخشی از تجهیزات یا تغییر روش پشتیبانی باشد. خرید زمانی در پیشنهاد قرار میگیرد که ارتباط آن با نیاز و نتیجه مورد انتظار روشن باشد.
نیازسنجی چه تفاوتی با طراحی فنی دارد؟
نیازسنجی مسئله، نیاز و محدودیت را مستند میکند. طراحی فنی با استفاده از این اطلاعات، معماری، پیکربندی و روش اجرا را تعیین میکند. در پروژه پیچیده، یافتههای طراحی ممکن است نیاز به بررسی تکمیلی ایجاد کنند.