چرخه‌ی حیات نرم‌افزار در ITIL4: از جرقه تا فاجعه! در این مقاله کاربردی می‌خوانید: هر نرم‌افزاری، با یک ایده شروع می‌شود. تصور کنید در سازمان ما، بخش منابع انسانی نیاز به یک سامانه‌ی ارزیابی عملکرد دارد. من بعنوان مدیر خدمات فناوری اطلاعات، این نیاز را دریافت می‌کنم. حالا، مسیر چرخه حیات آغاز می‌شود. این را حال به کسب‌وکار تعمیم دهید فرض کنید نیازی را شناسایی کرده‌اید یا مشتری از شما چیزی خواسته. چطور شروع کنیم؟ 1. ایده‌پردازی تا طراحی – Engage + Plan در مرحله‌ی نخست، نیاز کسب‌وکار را مستند می‌کنیم (فرایند Engage). سپس، در چارچوب ITIL 4 با کمک Plan، یک برنامه‌ی دقیق شامل منابع، بودجه، ریسک‌ها و نقاط عطف آماده می‌سازیم. طراحی اولیه نرم‌افزار (High-Level Design) حاصل همین مرحله است. 2. ساخت، تست و انتقال – Design & Transition + Build در این مرحله با همکاری تیم توسعه و تست، محصول ساخته می‌شود و فرایند Design and Transition وارد فاز عملیاتی می‌گردد. اینجاست که اهمیت DevOps یا Agile به کمکمان می‌آید. با استفاده از Continuous Integration/Deployment، استقرار اولیه (Pilot) انجام و در محیط محدود بررسی می‌شود. 3. اجرا و پشتیبانی – Deliver & Support نرم‌افزار وارد فاز بهره‌برداری می‌شود. کاربران از آن استفاده می‌کنند و ما، با کمک فرایند Incident Management، پشتیبانی مستمر ارائه می‌دهیم. هر مشکل به‌سرعت ثبت، اولویت‌بندی و رفع می‌شود. 4. ارزیابی ارزش – Improve چند ماه بعد، با داده‌های واقعی، ROI را محاسبه می‌کنیم. آیا زمان صرفه‌جویی شد؟ هزینه‌ها کاهش یافت؟ رضایت کاربران بالا رفت؟ اگر پاسخ مثبت است، پس به هدف رسیده‌ایم. در غیر این‌صورت، وارد چرخه‌ی Continual Improvement می‌شویم. فرایندهای کلیدی در چرخه‌ی حیات نرم‌افزار (بر اساس ITIL 4):

در چارچوب ITIL 4، جداسازی استقرار (Deployment) از انتشار (Release) بخشی از تمرین‌های پیشرفته در دو حوزه‌ی Release Management و Deployment Management محسوب می‌شود. ITIL 4 تأکید دارد که انتشار یک تغییر برای کاربران نهایی نباید الزاماً همزمان با استقرار فنی آن باشد. این رویکرد، که با استفاده از ابزارهایی مانند feature toggles، blue-green deployment یا canary releases پشتیبانی می‌شود، امکان تحویل ارزش به‌صورت امن، کنترل‌شده و با ریسک کمتر را فراهم می‌کند. در ITIL 4، تمرکز بر مدیریت ارزش کسب‌وکار است، نه صرفاً تحویل تغییر، و این جداسازی دقیقاً همین هدف را محقق می‌کند. قبل از بررسی این جداسازی بیایید یک سناریو واقعی را بررسی کنیم. نجات پروژه فروشگاه آنلاین در یک جمعه سیاه سناریو: شرکت ایکس بعنوان مالک یک پلتفرم فروشگاهی بزرگ در کشور، تصمیم می‌گیرد یک فیچر پیشنهاد هوشمند را برای افزایش فروش محصولات خود فعال کند. ویژگی‌ها کاملاً تست شده‌اند، اما ریسک اصلی زمان انتشار است: جمعه سیاه، ساعت ۹ صبح. تیم مجبور است ویژگی جدیدی را در روز جمعه سیاه ارائه دهد. یک اشتباه کوچک در این روز می‌تواند میلیون‌ها تومان خسارت وارد کند. در اینجا، جدا کردن استقرار از انتشار راه‌حلی نجات‌بخش می‌شود. این یعنی شرکت ایکس به‌جای انتشار مستقیم تصمیم می‌گیرد: نتیجه:نه‌تنها سیستم بدون مشکل کار کرد، بلکه فروش آن روز ۲۷٪ افزایش یافت. مشتریان هم تجربه بهتری داشتند جدا کردن استقرار از انتشار باعث شد تیم بتواند بدون نگرانی از بروز خطا در زمان اوج ترافیک، کنترل کامل بر ویژگی جدید داشته باشد. این رویکرد نه فقط در جمعه سیاه، بلکه در هر به‌روزرسانی مهمی ضروری است. در جدول زیر، دو تکنیک مهم در جداسازی استقرار (Deployment) از انتشار (Release) در چارچوب ITIL 4 — یعنی Feature Toggle و Canary Release — به صورت مقایسه‌ای شرح داده شده‌اند: جدول مقایسه Feature Toggle و Canary Release تکنیک‌های Feature Toggle و Canary Release سابقه‌ای چندده‌ساله در مهندسی نرم‌افزار دارند، اما با گسترش متدلوژی‌های چابک (Agile) و DevOps، نقش آن‌ها در مدیریت تغییر و انتشار بسیار پررنگ‌تر شده است. Feature Toggle نخستین بار توسط توسعه‌دهندگان در شرکت‌هایی مثل Flickr و Facebook مورد استفاده قرار گرفت تا ویژگی‌هایی را در محیط production مستقر کنند اما تنها برای گروه خاصی از کاربران یا در شرایط خاص فعال نمایند. این روش به تیم‌ها اجازه می‌دهد بدون نیاز به بازاستقرار، ویژگی‌ها را روشن یا خاموش کرده و کنترل دقیق‌تری بر زمان و نحوه انتشار داشته باشند. از سوی دیگر، Canary Release الهام‌گرفته از روش‌های ایمنی در معادن (استفاده از قناری‌ها برای شناسایی گازهای سمی) است و اولین بار در مقیاس وسیع توسط Google و Netflix به‌کار گرفته شد. این تکنیک به تیم‌ها اجازه می‌دهد تا نسخه‌ی جدیدی از نرم‌افزار را ابتدا برای درصد محدودی از کاربران منتشر کرده و در صورت عدم مشاهده مشکل، آن را به کل کاربران گسترش دهند. هر دو روش امروز بخشی جدایی‌ناپذیر از استراتژی‌های مدرن انتشار در چارچوب‌هایی مانند ITIL 4، Site Reliability Engineering (SRE) و Continuous Delivery هستند. ویژگی / تکنیک Feature Toggle (کلید ویژگی) Canary Release (انتشار قناری‌وار) تعریف مکانیسمی در کد که به شما اجازه می‌دهد یک ویژگی را بدون تغییر در کد اصلی فعال یا غیرفعال کنید. نوعی انتشار تدریجی که ابتدا تنها برای درصد کمی از کاربران فعال می‌شود. هدف اصلی جدا کردن زمان استقرار از زمان فعال‌سازی ویژگی برای کاربران. شناسایی مشکلات احتمالی در مقیاس کوچک قبل از انتشار عمومی. نحوه اجرا از طریق پارامترهای پیکربندی یا ابزارهای third-party (مثلاً LaunchDarkly، Unleash). با تقسیم ترافیک به چند گروه و هدایت آن به نسخه جدید از نرم‌افزار در محیط production. مزیت کلیدی کنترل لحظه‌ای و سریع بر فعال‌سازی ویژگی‌ها بدون نیاز به استقرار مجدد. کاهش ریسک انتشار و امکان rollback سریع در صورت بروز مشکل. مناسب برای ویژگی‌های بزرگ […]

یک ITIL مینیمال و کاربردی در جلساتی مدیریتی، پرسشی که برخی از مدیران ارشد یا مدیران فناوری اطلاعات می‌پرسند این است که کدام فرایندها را باید پیاده کنیم؟ پرسش هوشمندانه‌ای است، و اتفاقاً یکی از دغدغه‌های رایج مدیران در مسیر پیاده‌سازی ITIL همین است: “کدام فرایندها را پیاده کنیم؟ همه یا فقط چند مورد؟” اینجا مسئله پول و زمان نیست؛ بلکه مهمتر از آن آیتم‌های دیگری است که باید در پاسخ بدان پرداخت بعبارتی پاسخ این است که: ITIL4 حدود ۳۴ تمرین دارد. پیاده‌سازی کدام تمرینات بستگی شدیدی به بلوغ سازمان شما، دردها و دغدغه‌هایتان دارد. لازم نیست همه‌ی فرایندهای ITIL را اجرا کنید. باید آن‌هایی را اجرا کنید که: فرایندهایی که بیشتر سازمان‌ها با آن‌ها شروع می‌کنند: فرایند چرا انتخاب می‌شود؟ مناسب چه وضعیتی است؟ Incident Management برای کاهش زمان پاسخ‌گویی به مشکلات کاربران اگر کاربران شکایت زیادی دارند Request Fulfillment برای مدیریت درخواست‌های تکراری (مثل نصب نرم‌افزار) اگر Helpdesk غرق در درخواست‌هاست Change Enablement برای جلوگیری از تغییرات غیرمجاز و کاهش ریسک اگر تغییرات باعث اختلال می‌شوند Asset & Configuration Management برای دانستن چی داریم و کجا هست اگر دارایی‌ها گم می‌شوند یا پشتیبانی دشوار است Knowledge Management برای مستندسازی راه‌حل‌های پرتکرار اگر حل تکراری مشکلات وقت زیادی می‌گیرد راهنمای انتخاب: برای شروع حداقلی و مؤثر با چارچوب ITIL (یا همان Minimum Viable ITIL)، بهتر است فقط فرایندهایی را اجرا کنید که بیشترین ارزش را با کمترین تلاش ایجاد می‌کنند. در اینجا یک نقشه راه ساده و کاربردی برای شروع آورده‌ایم: هدف: ساخت یک ITIL مینیمال و کاربردی برای بهبود خدمات IT Minimum Viable ITIL یا به‌اختصار MVI، به معنی «حداقل چارچوب لازم از ITIL برای شروعی مؤثر» است. این رویکرد بر این اصل استوار است که شما لازم نیست کل ITIL را یکجا پیاده‌سازی کنید؛ بلکه باید با ساده‌ترین و مهم‌ترین فرایندهایی شروع کنید که بیشترین ارزش را با کمترین پیچیدگی ایجاد می‌کنند. تعریف ساده: Minimum Viable ITIL یعنی انتخاب و اجرای فقط همان بخش‌هایی از ITIL که برای شروع، بیشترین دردهای IT سازمان را درمان می‌کنند. اهداف Minimum Viable ITIL: مثال یک MVI واقعی: یک سازمان می‌تواند فقط با ۳ فرایند زیر شروع کند: و به‌تدریج فرایندهایی مانند Asset Management یا Problem Management را اضافه کند. یک نقشه‌راه حداقلی! 1. تمرکز روی سه فرایند حیاتی (Core Trio): فرایند چرا مهم است؟ ابزار پیشنهادی Incident Management پاسخ سریع به مشکلات کاربران Jira, ServiceDesk Plus Change Enablement مدیریت تغییرات بدون ریسک Jira Change Workflow Service Request Management پاسخ به درخواست‌های تکراری (مثلاً نصب نرم‌افزار) Self-service Portal 2. تعریف MVP هر فرایند (Minimum Viable Process): مثلاً برای Incident Management: 3. یک داشبورد ساده برای KPIهای اصلی: 4. ارتباط با کاربران (Communication): 5. بازخورد و بهبود تدریجی: جدول تصمیم‌گیری برای انتخاب فرایندهای ITIL مسأله یا درد سازمانی فرایند پیشنهادی ITIL هدف اجرای این فرایند کاربران از کندی یا بی‌پاسخ بودن پشتیبانی شکایت دارند Incident Management ثبت، پیگیری و حل سریع مشکلات درخواست‌های تکراری مثل نصب نرم‌افزار یا دسترسی زیاد شده‌اند Service Request Management نظم‌دهی به درخواست‌های پرتکرار تغییرات فنی باعث قطعی یا اختلال در سرویس‌ها می‌شوند Change Enablement کنترل و ارزیابی تغییرات پیش از اجرا کسی نمی‌داند چه دارایی‌هایی داریم یا کجا هستند Asset & Configuration Management ثبت و پیگیری تجهیزات IT نیروها مجبورند مشکلات را بارها از نو حل کنند Knowledge Management مستندسازی راه‌حل‌های پرتکرار گزارش‌گیری از عملکرد IT امکان‌پذیر نیست Service Level Management تعیین و پایش سطح خدمات (SLA) اولویت‌بندی درست بین کارها وجود ندارد Incident & Request Prioritization نظم‌دهی بر اساس اولویت تجاری نکته کلیدی: برای شروع، فقط 2 تا 3 مورد اول را پیاده‌سازی کنید. بقیه را به‌مرور و بر اساس نیاز اضافه کنید. برای طراحی یک سناریوی دقیق Minimum Viable ITIL (MVI) برای شما، لازم دارم […]

مدیرانی که تیکتینگ را دوست دارند، البته فقط برای دیگران! در جلسات مدیریتی، «نظام‌مند شدن امور»، «مستندسازی فرایندها» و «قابل ردیابی بودن درخواست‌ها» از جمله کلیدواژه‌هایی هستند که مدیران ارشد با شور و حرارت از آن‌ها دفاع می‌کنند. در اغلب صورتجلسه‌ها، می‌خوانیم که: «همه واحدها ملزم به استفاده از سامانه تیکتینگ هستند.» اما به‌محض این‌که پای خود این عزیزان به میان می‌آید، انگار نه انگار! یا تماس مستقیم می‌گیرند، یا از طریق منشی و واتساپ پیام می‌فرستند، یا یک جمله نصفه‌نیمه در یک جلسه درگوشی می‌گویند و انتظار دارند ۲ دقیقه بعد، درخواستشان انجام شده باشد — بدون هیچ ردی از درخواست، بدون SLA، بدون شفافیت. شاید تیکت زدن، کاری دون شأن مدیریت تلقی می‌شود؛ یا شاید فکر می‌کنند سرعت کار پایین می‌آید. اما واقعیت این است: تا وقتی مدیران خودشان الگوی استفاده از سامانه نباشند، هیچ سامانه‌ای موفق نخواهد شد. چرا مدیران ارشد از سیستم تیکتینگ استفاده نمی‌کنند؟ سامانه‌های مدیریت تیکت (Helpdesk / ServiceDesk) یکی از ابزارهای کلیدی برای پیگیری شفاف درخواست‌ها، کاهش خطای انسانی، و افزایش بهره‌وری پاسخ‌گویی در سازمان‌ها هستند. با این حال، در بسیاری از سازمان‌ها، مشاهده می‌شود که مدیران ارشد تمایلی به ثبت تیکت ندارند و ترجیح می‌دهند درخواست‌های خود را به صورت شفاهی، تلفنی یا غیررسمی مطرح کنند. این رفتار می‌تواند باعث گم‌شدن اطلاعات، نبود ردیابی، و افزایش بار کاری نامنظم برای تیم‌های اجرایی شود. ما در مدانت بررسی جامعی کرده‌ایم و تحلیل دلایل استفاده نکردن مدیران از سیستم تیکتینگ را در موارد زیر دسته‌بندی کردیم: نوع دلیل شرح مشکل پیامدها فرهنگی/روانی مدیران ممکن است ثبت تیکت را کاری سطح پایین بدانند کاهش مشارکت در فرایند رسمی و مستند فرهنگی/روانی تمایل به ارسال درخواست شفاهی به دلیل حس تسلط یا سرعت بیشتر نبود پیگیری دقیق یا مستندات معتبر فرهنگی/روانی تجربه‌ی منفی از پاسخگویی کند یا بی‌نتیجه در گذشته بی‌اعتمادی به سامانه فنی/کاربری نداشتن دسترسی یا رابط کاربری پیچیده بی‌میلی به استفاده از سیستم فنی/کاربری نبود نسخه ساده‌شده یا موبایل‌پسند سامانه نارضایتی از تجربه کاربری سازمانی/ساختاری نبود فرهنگ پاسخگویی ساختارمند در کل سازمان تضعیف نقش فرآیندهای رسمی فنی/کاربری نبود گزارش‌گیری و تحلیل مؤثر از تیکت‌های مدیریتی عدم احساس ارزشمند بودن ثبت تیکت عدم مشارکت مدیران ارشد در استفاده از سامانه‌های تیکتینگ، نه‌تنها باعث کاهش نظم و شفافیت فرآیندهای پشتیبانی می‌شود، بلکه مانعی جدی در نهادینه‌سازی فرهنگ پاسخ‌گویی ساختارمند در سازمان است. این موضوع هم به کارایی تیم‌های فنی لطمه می‌زند و هم فرصت‌های گزارش‌گیری و بهبود مستمر را محدود می‌سازد. پیشنهادها و راهکارها مدیران ارشد نیز شبیه کاربران در برابر این تغییر مقاومت نشان می‌دهد اما راهکارهایی هست که می‌شود با استفاده از آن بر چالشها غلبه کرد که بشرح ذیل است: راهکار شرح اقدام آموزش اختصاصی و مختصر مدیران آموزش کاربردی و سریع درباره مزایای ثبت تیکت و نحوه استفاده از سیستم ایجاد پنل VIP یا ساده‌سازی رابط طراحی یک تجربه کاربری مناسب برای مدیران، با فرم‌های ساده‌تر و پاسخ سریع‌تر اولویت‌بندی تیکت‌های مدیریتی تعریف SLA اختصاصی برای تیکت‌های ثبت‌شده توسط مدیران گزارش‌دهی مستمر به مدیران ارائه گزارش ماهانه از درخواست‌های ثبت‌شده و حل‌شده به صورت گرافیکی فرهنگ‌سازی از بالا به پایین مشارکت مدیرعامل یا مدیر ارشد در ثبت تیکت به عنوان الگو برای دیگران این یعنی: مشارکت مدیران ارشد در سیستم تیکتینگ نه‌تنها نشانه‌ی نظم و مسئولیت‌پذیری است، بلکه نقش مهمی در افزایش بهره‌وری سازمان دارد. راهکارهای پیشنهادی می‌تواند زمینه‌ساز پذیرش بیشتر و بهره‌مندی از مزایای واقعی سیستم‌های تیکتینگ در سطوح بالای سازمان باشد. اما کارهای بیشتری هم می‌توان کرد در ادامه، راهکارهای کاملاً عملی و قابل اجرا در سطح سازمان برای تشویق مدیران به استفاده از سیستم تیکتینگ ارائه شده است. این راهکارها هم جنبه فرهنگی دارند و هم اجرایی، و به سادگی می‌توان آن‌ها را به مرحله اجرا رساند: ۱. طراحی […]

چگونگی شناسایی و مدیریت دارایی‌های حیاتی و مهم مواردی از این دست را دیده یا شنیده‌اید؛ این معضل فقط در کشور ما نیست در سراسر جهان کم‌وبیش هست. شناسایی و مدیریت دارایی‌های حیاتی و مهم، بخش بسیار مهمی از فناوری اطلاعات است؛ برای مدیریت مؤثر دارایی‌های حیاتی و جلوگیری از سرقت یا گم‌شدن آن‌ها، استفاده از راهکارهای متنوع و هماهنگ بسیار اهمیت دارد. هر دارایی با توجه به اهمیت و نقش آن در کسب‌وکار نیازمند روش خاصی برای شناسایی و حفاظت است. در جدول زیر، مهم‌ترین راهکارهای شناسایی و مدیریت دارایی‌های حیاتی به همراه مزایا و محدودیت‌های هر کدام آورده شده است تا بتوانید با آگاهی بیشتر، بهترین روش‌ها را برای سازمان خود انتخاب کنید.: راهکار توضیح کوتاه مزایا محدودیت‌ها برچسب ضد سرقت (Anti-theft Tags)یا پلمپ سربی چسباندن برچسب‌های فیزیکی با اطلاعات هشدار و شناسه منحصر به فرد شناسایی سریع، بازدارندگی دزدی هزینه نصب و نگهداری، فقط برای دارایی‌های حیاتی مناسب است کد QR و بارکد نصب کدهای قابل اسکن برای ردیابی آسان و دسترسی سریع به اطلاعات ساده و سریع، کاهش خطاهای دستی نیاز به دستگاه اسکنر، مناسب برای دارایی‌های قابل حمل ردیابی بر اساس ایجنت(Agent-based Tracking) نصب نرم‌افزار روی دستگاه برای گزارش وضعیت و موقعیت لحظه‌ای مانیتورینگ دقیق و آنلاین، هشداردهی خودکار نیاز به نصب نرم‌افزار، پیچیدگی فنی بیشتر ارزیابی اهمیت دارایی (Criticality Assessment) ارزیابی دارایی‌ها بر اساس محرمانگی، یکپارچگی و دسترسی مورد نیاز تمرکز روی دارایی‌های مهم، بهینه‌سازی منابع نیاز به تحلیل دقیق و مستمر سیستم‌های مدیریت دارایی (Asset Management Software) نرم‌افزار جامع برای ثبت، پیگیری و گزارش‌گیری دارایی‌ها دید کامل، امکان گزارش‌گیری و تحلیل داده هزینه خرید و آموزش، نیاز به به‌روزرسانی مداوم اگر به دنبال راهکارهایی برای جلوگیری از سرقت دارایی‌های شرکت خود هستید، افزودن برچسب‌های ضد سرقت به تجهیزات‌تان در نگاه اول ایده‌ای منطقی به نظر می‌رسد. در واقع، مزایای آن واضح است: با نصب این برچسب‌های فیزیکی یا پلمپ‌های سربی می‌توانید سرقت دارایی‌ها را کاهش داده، از آن جلوگیری کنید و حتی دارایی‌های سرقت‌شده یا مفقود شده را بازیابی و مدیریت کنید. خیلی عالی به نظر می‌رسد، درست است؟ اما قبل از اینکه بی‌گدار به آب بزنید و چنین سیستمی را اجرا کنید، بهتر است دو قدم عقب‌نشینی کنید، نفس عمیقی بکشید و استراتژی خود را دوباره بررسی کنید. آیا سرقت دارایی در شرکت شما یک مشکل واقعی و فعلی است؟ آیا ممکن است در آینده به مشکلی تبدیل شود؟ اصلاً این مسئله در شرکت شما وجود دارد؟ این سوالات شاید ساده به نظر برسند، اما پاسخ به آن‌ها برای طراحی صحیح استراتژی مدیریت دارایی‌ها و اجتناب از انتخاب راه‌حلی پیچیده و نامتناسب با نیازهای واقعی شرکت بسیار مهم است. در این مقاله، مدانت توضیح می‌دهد که برچسب‌های ضد سرقت چیستند، برای چه کاربردی دارند و چه زمانی باید به استفاده از چنین سیستمی فکر کنید؟ و مهم‌تر از همه، درباره اینکه پیشگیری بهترین راهکار برای کسانی است که نگران دارایی‌های خود هستند، صحبت خواهد کرد. برچسب‌های ضد سرقت دارایی‌ها چه کاربردی دارند؟ این برچسب‌ها، برچسب‌هایی مقاوم و غیرقابل دستکاری هستند که برای محافظت از دارایی‌های باارزش طراحی شده‌اند. معمولاً به شکل استیکر روی دارایی‌ها نصب می‌شوند و با ذکر اینکه دارایی تحت نظارت است، دزد را منصرف می‌کنند. همچنین اگر دارایی سرقت یا مفقود شود، این برچسب‌ها به گزارش و بازگرداندن آن کمک می‌کنند. ویژگی‌های برچسب‌های ضد سرقت چیست؟ برچسب‌ها شامل متن هشدار، کد QR یا بارکد برای دسترسی سریع به اطلاعات دارایی، شماره سریال منحصر به فرد و اطلاعات تماس هستند تا پیگیری و بازگرداندن دارایی‌ها آسان‌تر شود. آیا سازمان شما باید نگران سرقت دارایی باشد؟ اگر مدیر دارایی‌ها هستید، باید نگران باشید؛ چون سرقت دارایی‌ها پیامدهای گسترده‌ای دارد: از دست دادن دارایی گرفته تا تهدید امنیت شرکت و کاهش بهره‌وری […]