اگر هر واحد فناوری اطلاعات برای هر مسئله یک فایل، یک گروه پیام‌رسان و یک گزارش جدا دارد، مشکل کمبود ابزار نیست؛ مشکل این است که جریان کار مشترک و قابل‌اندازه‌گیری نداریم.
خیلی از سازمان‌ها با خرید نرم‌افزار شروع می‌کنند، در حالی که نقطه شروع واقعی باید یک تصویر ساده از کار روزانه باشد: درخواست کاربر از کجا وارد می‌شود، چه کسی آن را می‌بیند، تصمیم تغییر کجا ثبت می‌شود، دارایی مرتبط چیست و مدیر در پایان ماه چه چیزی می‌خواهد بداند.
این راهنما یک برنامه فشرده ۹۰ روزه است؛ نه برای رسیدن به بلوغ کامل، بلکه برای این‌که سازمان از وضعیت «هرکس به روش خودش» به یک مدل قابل‌تکرار برسد. اگر این پایه درست ساخته شود، بعداً اضافه‌کردن اتوماسیون، مانیتورینگ، GRC یا گزارش‌های مدیریتی بسیار کم‌هزینه‌تر خواهد بود.
سناریو: واحد فناوری اطلاعاتی که پرکار است اما قابل‌اندازه‌گیری نیست
فرض کنید یک شرکت ۴۰۰ نفره، ۸ کارشناس فناوری اطلاعات و چند سامانه حیاتی دارد. درخواست‌ها از تلفن، واتساپ، ایمیل و مراجعه حضوری می‌آیند. خرابی اینترنت با درخواست نصب نرم‌افزار در یک صف قرار می‌گیرد. فهرست دارایی‌ها در اکسل است و تغییرات مهم شبکه بیشتر در ذهن چند نفر باتجربه می‌ماند.
مدیر فناوری اطلاعات می‌داند تیمش کار می‌کند، اما برای جلسه مدیریت نمی‌تواند با اطمینان بگوید بیشترین اتلاف وقت کجاست، کدام سرویس بیشتر آسیب می‌بیند، چند تغییر بدون برنامه انجام شده یا کدام ریسک‌ها واقعاً پیگیری شده‌اند. هدف ۹۰ روز اول، پاسخ‌دادن به همین پرسش‌هاست.
مسئله را درست تعریف کنیم
در ۹۰ روز اول لازم نیست همه فرایندهای ITIL را پیاده کنید. بهتر است زنجیره‌ای را بسازید که اطلاعات در آن به هم متصل شوند: کاربر یک نیاز را ثبت می‌کند، نیاز به یک سرویس مربوط می‌شود، سرویس روی دارایی‌ها تکیه دارد، تغییرات روی همان دارایی‌ها اثر می‌گذارند و ریسک و گزارش مدیریتی از همین داده‌ها شکل می‌گیرند.
اگر این ارتباط ایجاد نشود، حتی بهترین داشبوردها هم فقط مجموعه‌ای از عددهای جدا از هم خواهند بود.
| بازه | خروجی اصلی | نشانه موفقیت |
|---|---|---|
| روز ۱ تا ۱۵ | یک کانال رسمی ثبت کار و دسته‌بندی اولیه | بیش از ۸۰٪ درخواست‌ها از مسیر مشخص وارد می‌شوند |
| روز ۱۶ تا ۳۰ | تفکیک Incident و Request و تعریف SLA اولیه | اولویت‌ها و زمان پاسخ قابل‌گزارش می‌شوند |
| روز ۳۱ تا ۴۵ | فهرست دارایی‌های کلیدی و مالک هر دارایی | تیکت‌های مهم به دارایی مرتبط می‌شوند |
| روز ۴۶ تا ۶۰ | ثبت تغییرات و حداقل تقویم تغییر | تغییر اضطراری از تغییر برنامه‌ریزی‌شده جداست |
| روز ۶۱ تا ۷۵ | فهرست ریسک‌های فناوری و اقدام اصلاحی | هر ریسک مالک و موعد پیگیری دارد |
| روز ۷۶ تا ۹۰ | داشبورد مدیریتی یک‌صفحه‌ای | مدیریت روند، گلوگاه و اقدام بعدی را می‌بیند |
مسیر اجرایی پیشنهادی
1. یک ورودی رسمی برای کار بسازید
قرار نیست تلفن و گفت‌وگو حذف شوند؛ اما نتیجه هر درخواست باید در یک سامانه ثبت شود. تیم باید بداند «اگر ثبت نشده، قابل‌پیگیری نیست». این جمله به مرور رفتار کاربران و کارشناسان را یکدست می‌کند.
2. چهار مفهوم را از هم جدا کنید
رخداد، درخواست خدمت، مشکل و تغییر چهار برچسب تزئینی نیستند. خرابی سرویس باید مسیر متفاوتی از درخواست دسترسی داشته باشد؛ مشکل باید ریشه تکرار رخداد را پیدا کند و تغییر باید تصمیم کنترل‌شده برای دست‌کاری محیط باشد.
3. از دارایی‌های حیاتی شروع کنید، نه همه چیز
اول سراغ سرورها، تجهیزات شبکه، سرویس‌های اصلی و ایستگاه‌های کاری حساس بروید. ثبت همه اقلام کم‌ارزش در شروع، تیم را خسته می‌کند. دارایی باید به مالک، کاربر، سرویس و رخداد قابل‌اتصال باشد.
4. تغییرات را قابل‌مشاهده کنید
برای هر تغییر مهم حداقل دلیل، اجراکننده، زمان، ریسک، برنامه بازگشت و نتیجه را ثبت کنید. هدف ایجاد بروکراسی نیست؛ هدف این است که اگر فردا سرویس از کار افتاد، بدانیم شب گذشته چه چیزی تغییر کرده است.
5. گزارش مدیریتی را به تصمیم وصل کنید
تعداد تیکت به‌تنهایی شاخص مدیریتی نیست. روند رخداد تکراری، زمان بازیابی، درصد تغییر موفق، دارایی‌های پرریسک و کارهای عقب‌مانده باید به تصمیم بعدی منجر شوند. هر نمودار بدون تصمیم احتمالی، یک نمودار اضافه است.
از کجا بفهمیم مسیر درست است؟
پس از سه ماه باید بتوانید با چند کلیک پاسخ دهید: بیشترین تقاضا مربوط به کدام خدمت است؟ کدام دارایی بیشترین رخداد را داشته؟ چه تغییراتی ناموفق بوده؟ کدام ریسک موعدش گذشته؟ و تیم در ماه آینده دقیقاً روی چه چیزی تمرکز می‌کند؟
اگر پاسخ‌ها هنوز از چند نفر و چند فایل جمع می‌شوند، پروژه هنوز به نقطه «سیستم کاری مشترک» نرسیده است.
خطاهای رایج
- شروع هم‌زمان ده‌ها فرایند و خسته‌کردن تیم با فرم‌های طولانی.
- اندازه‌گیری تعداد تیکت به جای کیفیت، زمان بازیابی و نتیجه خدمت.
- واردکردن هزاران دارایی بدون مالک، رابطه و کاربرد مدیریتی.
- ساخت داشبورد قبل از تعریف داده و مسئولیت.
لینک‌های داخلی برای ادامه مطالعه
جمع‌بندی
یک نقشه راه خوب فناوری اطلاعات از خرید ابزار شروع نمی‌شود؛ از تعریف جریان کار و داده‌ای شروع می‌شود که تیم حاضر است هر روز آن را به‌روز نگه دارد.
در ۹۰ روز، هدف «کامل‌شدن» نیست. هدف این است که سازمان یک زبان مشترک، یک مسیر ثبت، چند رابطه مهم و چند شاخص قابل‌اعتماد داشته باشد. از آن نقطه به بعد، بلوغ واقعی تازه قابل‌ساختن است.
کلیدواژه‌های این راهنما: نقشه راه مدیریت فناوری اطلاعات، ITSM، Service Desk، مدیریت دارایی IT، مدیریت تغییر، مدیریت ریسک فناوری اطلاعات
