مشکلات تماس تلفنی در فناوری اطلاعات
از لینک زیر بخوانید
https://servicedesk.medanet.ir/phonically-issues/
از لینک زیر بخوانید
https://servicedesk.medanet.ir/phonically-issues/
مدیریت زمان در مدیریت خدمات
از لینک زیر بخوانید
https://servicedesk.medanet.ir/time-management-on-itsm/
از لینک زیر بخوانید
https://servicedesk.medanet.ir/time-management-on-itsm/
ساختار شکست کار
"سنگ بزرگ نشانهی نزدن است!" این یک واقعیت است. یک پروژه، سنگ بزرگ است. هیچکس با تعریف کردن یک عنوان پروژه قادر به انجام تمام جزئیات آن نخواهد بود. ساختار شکست کار یا WBS که اختصار Work Breakdown Structure است به معنای خُرد کردن پروژه به قطعات کوچکتر است تا بتوان از پس انجام برآییم. در پروژههای فناوری بخصوص در چارچوب ITIL، تغییرات زیادی مدنظر هست که اغلب آنها درگیر تمرین مدیریت پروژه نیز میشوند. برای پیشبرد چنین تغییراتی بویژه اگر از نوع تغییرMajor باشند. استفاده از مدیریت پروژه و ساختار شکست کار مهمترین قسمت از انجام تغییرات تایید شده است. یک پروژه را باید در فازها یا Milestone-هایی تقسیمبندی نمود و هر فاز میتواند شامل چندین کار باشد. توزیع منابع و برنامهریزی اجرای یک پروژه امکان راهبری صحیح و کنترلشدهی آنرا میسر میکند. شکست پروژه به قطعات ریز به معنای بسط دادن و کُند کردن آن نیست. بلکه برای تعیین دقیق حدود دسترسی و تخصیص شرح وظایف است. چیزی که در مدیریت پروژه باید بخوبی لحاظ کرد اینست که دچار پارکینسون پروژه نشویم. این یعنی زمان تخمینی و یا Deadline را آنقدر باز در نظر نگیریم که ماهها طول بکشد تا کوچکترین جز پروژه (کار) را انجام دهیم. آنقدر منابع در اختیار پروژه قرار ندهیم که کار، لَخت پیش برود. زیرا بر اساس قانون پارکینسون پروژه هر چقدر منابع تخصیص دهید و هر چقدر زمان اجرا را بسط دهید به همان اندازه، برای اجرای چنین پروژهای منابع و زمان مصرف خواهد شد و این به مثابه هدر رفت منابع است!
سنگ بزرگ را خُرد کنید و سنگهای کوچک را به موقع و با کمترین زمان و کمترین منابع بردارید.
www.MedaNet.ir
"سنگ بزرگ نشانهی نزدن است!" این یک واقعیت است. یک پروژه، سنگ بزرگ است. هیچکس با تعریف کردن یک عنوان پروژه قادر به انجام تمام جزئیات آن نخواهد بود. ساختار شکست کار یا WBS که اختصار Work Breakdown Structure است به معنای خُرد کردن پروژه به قطعات کوچکتر است تا بتوان از پس انجام برآییم. در پروژههای فناوری بخصوص در چارچوب ITIL، تغییرات زیادی مدنظر هست که اغلب آنها درگیر تمرین مدیریت پروژه نیز میشوند. برای پیشبرد چنین تغییراتی بویژه اگر از نوع تغییرMajor باشند. استفاده از مدیریت پروژه و ساختار شکست کار مهمترین قسمت از انجام تغییرات تایید شده است. یک پروژه را باید در فازها یا Milestone-هایی تقسیمبندی نمود و هر فاز میتواند شامل چندین کار باشد. توزیع منابع و برنامهریزی اجرای یک پروژه امکان راهبری صحیح و کنترلشدهی آنرا میسر میکند. شکست پروژه به قطعات ریز به معنای بسط دادن و کُند کردن آن نیست. بلکه برای تعیین دقیق حدود دسترسی و تخصیص شرح وظایف است. چیزی که در مدیریت پروژه باید بخوبی لحاظ کرد اینست که دچار پارکینسون پروژه نشویم. این یعنی زمان تخمینی و یا Deadline را آنقدر باز در نظر نگیریم که ماهها طول بکشد تا کوچکترین جز پروژه (کار) را انجام دهیم. آنقدر منابع در اختیار پروژه قرار ندهیم که کار، لَخت پیش برود. زیرا بر اساس قانون پارکینسون پروژه هر چقدر منابع تخصیص دهید و هر چقدر زمان اجرا را بسط دهید به همان اندازه، برای اجرای چنین پروژهای منابع و زمان مصرف خواهد شد و این به مثابه هدر رفت منابع است!
سنگ بزرگ را خُرد کنید و سنگهای کوچک را به موقع و با کمترین زمان و کمترین منابع بردارید.
www.MedaNet.ir
Forwarded from [ S o r o u s h a n e ]
فارغ از شوخی و متلکهایی که به قطعی سراسری شبکههای فیسبوک، اینستاگرام و واتساپ شده، در حوزهی مدیریت خدمات با چارچوب ITIL این اتفاق، یک مشکل ناشناخته است. چنین مشکلاتی در هر کسب و کاری بخصوص فناوری اطلاعات بهوفور رخ میدهد فیسبوک پیش از مالکیت اینستاگرام و واتساپ هم چالشهایی از این دست در سطح جهانی داشته.
--------
اساس کار مدیریت مشکل برای حل مسئله در این سناریو بدین گونه است:
اندازهگیری تاثیر خرابی؟: آیا مشکل فقط در برخی نقاط جهان است یا همه: تمام جهان.
علائم خرابی؟: باز نشدن اپلیکیشنهای مرتبط و وبسایت
دلیل و عامل خرابی؟: دلیل قطع شدن این سرویسها بلافاصله مشخص نشده. با این حال، چندین کارشناس امنیتی به سرعت، وجود مشکل در سیستم نام دامنه (DNS) به عنوان عامل احتمالی یاد کردند. آزمایشات آن نشان میدهد که قطع شدن به دلیل نقص مداوم DNS است.(DNS نام وب سایتها را به آدرسهای اینترنتی IP ترجمه میکند که توسط رایانه قابل خواندن است. اغلب به آن "دفترچه تلفن اینترنت" نیز میگویند.)
راهکار موقت؟: شاید با دسترسی کاربران از طریق IP و حذف موقت DNS مشکل در برخی نقاط بطور موقت مرتفع شود.
راهکار دائم؟: پس از مشخص شدن علت و آزمایشات انجام شده، راهحل دائمی برای آن ارایه میشود تا از وقوع دوباره و عود مجدد مشکل جلوگیری گردد.
آیا این یک خطای شناخته شده بود؟: قطعاً خیر. زیرا در حد شرکت بزرگ و چندملیتی اگر چنین مشکلی از قبل رخ داده بود برچسب خطای شناخته شده میگرفت و سریعاً رفع رجوع میشد.
زمان حل مشکل؟: نامشخص! بدلیل عدم شناخت علت و عامل خرابی.
-------
بهترین کار در چنین شرایطی، علیرغم اینکه میلیونها دلار این شرکت را زیانده خواهد کرد، حفظ خونسردی است. سپس اطلاعرسانی عمومی برای جلوگیری از ترافیک درخواستها، بازخوردها و عدم تزریق استرس بیشتر به کارشناسان فنی و در آخر استفاده از راهکارهای موقت برای به حالت اول بازگرداندن سرویس ولو موقتی.
در آمریکا، بسیاری از مردم، اینترنت را همین شبکههای محبوب مینامند. جدای از زیان این شرکت، کسب و کارهای بیشماری متحمل خسارت میشوند.
بهرحال این یک مشکل است و طبق مدیریت مشکل نیازمند زمان، تحلیل و آزمایش برای رفع ریشهای آن است.
www.Soroushane.ir
--------
اساس کار مدیریت مشکل برای حل مسئله در این سناریو بدین گونه است:
اندازهگیری تاثیر خرابی؟: آیا مشکل فقط در برخی نقاط جهان است یا همه: تمام جهان.
علائم خرابی؟: باز نشدن اپلیکیشنهای مرتبط و وبسایت
دلیل و عامل خرابی؟: دلیل قطع شدن این سرویسها بلافاصله مشخص نشده. با این حال، چندین کارشناس امنیتی به سرعت، وجود مشکل در سیستم نام دامنه (DNS) به عنوان عامل احتمالی یاد کردند. آزمایشات آن نشان میدهد که قطع شدن به دلیل نقص مداوم DNS است.(DNS نام وب سایتها را به آدرسهای اینترنتی IP ترجمه میکند که توسط رایانه قابل خواندن است. اغلب به آن "دفترچه تلفن اینترنت" نیز میگویند.)
راهکار موقت؟: شاید با دسترسی کاربران از طریق IP و حذف موقت DNS مشکل در برخی نقاط بطور موقت مرتفع شود.
راهکار دائم؟: پس از مشخص شدن علت و آزمایشات انجام شده، راهحل دائمی برای آن ارایه میشود تا از وقوع دوباره و عود مجدد مشکل جلوگیری گردد.
آیا این یک خطای شناخته شده بود؟: قطعاً خیر. زیرا در حد شرکت بزرگ و چندملیتی اگر چنین مشکلی از قبل رخ داده بود برچسب خطای شناخته شده میگرفت و سریعاً رفع رجوع میشد.
زمان حل مشکل؟: نامشخص! بدلیل عدم شناخت علت و عامل خرابی.
-------
بهترین کار در چنین شرایطی، علیرغم اینکه میلیونها دلار این شرکت را زیانده خواهد کرد، حفظ خونسردی است. سپس اطلاعرسانی عمومی برای جلوگیری از ترافیک درخواستها، بازخوردها و عدم تزریق استرس بیشتر به کارشناسان فنی و در آخر استفاده از راهکارهای موقت برای به حالت اول بازگرداندن سرویس ولو موقتی.
در آمریکا، بسیاری از مردم، اینترنت را همین شبکههای محبوب مینامند. جدای از زیان این شرکت، کسب و کارهای بیشماری متحمل خسارت میشوند.
بهرحال این یک مشکل است و طبق مدیریت مشکل نیازمند زمان، تحلیل و آزمایش برای رفع ریشهای آن است.
www.Soroushane.ir
چه زمانی باید از مدیریت خدمات استفاده کنیم!؟
۸ نشانه که در صورت مشاهده باید راه حل فعلی ارایهی خدمت را ترک کنید و به سیستم مدیریت خدمات مهاجرت کنید! این نشانهها را از لینک زیر میخوانید:
https://lnkd.in/eBguPCna
۸ نشانه که در صورت مشاهده باید راه حل فعلی ارایهی خدمت را ترک کنید و به سیستم مدیریت خدمات مهاجرت کنید! این نشانهها را از لینک زیر میخوانید:
https://lnkd.in/eBguPCna
Forwarded from [ S o r o u s h a n e ]
یک بام و دو هوا!
روی تمام سرورهایشان، ویندوزسرور نصب شده.
فایروال شبکهاشان، فورتیگیت است.
تجهیزات زیرساختاشان، همگی سیسکو.
مانیتورینگ شبکهاشان، سولارویندز.
اما به دنبال یک نرمافزار ایرانی برای مدیریت همهی اینها میگردند به این بهانه که به راهکارهای خارجی اطمینان ندارند!
www.Soroushane.ir
روی تمام سرورهایشان، ویندوزسرور نصب شده.
فایروال شبکهاشان، فورتیگیت است.
تجهیزات زیرساختاشان، همگی سیسکو.
مانیتورینگ شبکهاشان، سولارویندز.
اما به دنبال یک نرمافزار ایرانی برای مدیریت همهی اینها میگردند به این بهانه که به راهکارهای خارجی اطمینان ندارند!
www.Soroushane.ir
Forwarded from [ S o r o u s h a n e ]
شعر دو کاج و ITIL
شعر دو کاج در کتابهای مدرسه جدای از نشان دادن یک کاج بیرحم که به کاج بغلی کمک نکرد اما برخورد سیمبانان با آن، کاملاً مرتبط است با ITIL و حاوی تمرین مدیریت حادثه و مدیریت مشکل است. شاید شاعرش آقای محمدجواد محبت هرگز به این موضوع فکر نکرده بود. البته که نباید هم فکر میکرد؛ بههرحال مضمون شعر در چارچوب فناوری کاربردی دارد و در چارچوب انسانی، مضمونی!
مرکز ارتباط، دید آن روز / انتقال پیام، ممکن نیست
گشت عازم، گروه پیجویی / تا ببیند که عیب کار از چیست
سیمبانان پس از مرمت سیم / راه تکرار بر خطر بستند
یعنی آن کاج سنگ دل را نیز / با تبر، تکهتکه، بشکستند.
در انتهای شعر فوق دو بحث جالب مدیریت حادثه و مدیریت مشکل دیده میشود.
مدیریت حادثه، این بود که سیم انتقال پیام را مرمت کردند تا وضعیت فعلی به حالت عادی بازگردد. با این مصرع:" سیمبانان پس از مرمت سیم " پسازآن تمرین مدیریت مشکل انجامشده یعنی باید پس از شناسایی مشکل از وقوع مجدد و عود دوبارهی آن جلوگیری کرد. زیرا تکرر چنین حادثهای در آینده بازهم اتفاق خواهد افتاد و میتواند عواقب بدتری نیز به دنبال داشته باشد. بنابراین باید راه تکرار چنین مشکلی را بهطور ریشهای از بین بُرد. که خاتمهی شعر به همین تمرین میپردازد:" راه تکرار بر خطر بستند/ یعنی آن کاج سنگ دل را نیز / با تبر، تکهتکه، بشکستند.
این دو تمرین خوب را نه تنها در ITIL بلکه در تمام زندگی باید انجام دهیم!
www.Soroushane.ir
شعر دو کاج در کتابهای مدرسه جدای از نشان دادن یک کاج بیرحم که به کاج بغلی کمک نکرد اما برخورد سیمبانان با آن، کاملاً مرتبط است با ITIL و حاوی تمرین مدیریت حادثه و مدیریت مشکل است. شاید شاعرش آقای محمدجواد محبت هرگز به این موضوع فکر نکرده بود. البته که نباید هم فکر میکرد؛ بههرحال مضمون شعر در چارچوب فناوری کاربردی دارد و در چارچوب انسانی، مضمونی!
مرکز ارتباط، دید آن روز / انتقال پیام، ممکن نیست
گشت عازم، گروه پیجویی / تا ببیند که عیب کار از چیست
سیمبانان پس از مرمت سیم / راه تکرار بر خطر بستند
یعنی آن کاج سنگ دل را نیز / با تبر، تکهتکه، بشکستند.
در انتهای شعر فوق دو بحث جالب مدیریت حادثه و مدیریت مشکل دیده میشود.
مدیریت حادثه، این بود که سیم انتقال پیام را مرمت کردند تا وضعیت فعلی به حالت عادی بازگردد. با این مصرع:" سیمبانان پس از مرمت سیم " پسازآن تمرین مدیریت مشکل انجامشده یعنی باید پس از شناسایی مشکل از وقوع مجدد و عود دوبارهی آن جلوگیری کرد. زیرا تکرر چنین حادثهای در آینده بازهم اتفاق خواهد افتاد و میتواند عواقب بدتری نیز به دنبال داشته باشد. بنابراین باید راه تکرار چنین مشکلی را بهطور ریشهای از بین بُرد. که خاتمهی شعر به همین تمرین میپردازد:" راه تکرار بر خطر بستند/ یعنی آن کاج سنگ دل را نیز / با تبر، تکهتکه، بشکستند.
این دو تمرین خوب را نه تنها در ITIL بلکه در تمام زندگی باید انجام دهیم!
www.Soroushane.ir
بهترین درگاه برای ارتباط با کاربران
حتماً که خیلی روی محصولات و کیفیت آنان و زیرساختهای فناوری اطلاعات سرمایهگذاری میکنید. اما روی درگاههای ارتباط با مشتری چقدر سرمایه در نظر گرفتهاید؟ وقتی صحبت از سرمایه میشود مقصود، فقط خرج کردن پول نقد نیست، تخصیص نیروی انسانی و وقت گذاشتن برای شکلدادن و بهبود مستمر درگاههای ارتباطی خود بزرگترین سرمایهگذاری است و برگ برندهی بسیاری از سازمانهای موفق است.
طبق نظرسنجیی که برگزارشده امروزه ایمیل و پورتال سلفسرویس (درگاه خودخدمتی) متداولترین روش برای دسترسی به خدمات فناوری اطلاعات و دریافت پشتیبانی نسبت به تماس تلفنی است، در میان سازمانهای بررسی شده:
بیش از ۸۴٪ سازمانها از ایمیل برای ارایهی خدمات استفاده میکنند، ۸۲٪ پورتال سلف سرویس و 76٪ تلفن.
www.MedaNet.ir
حتماً که خیلی روی محصولات و کیفیت آنان و زیرساختهای فناوری اطلاعات سرمایهگذاری میکنید. اما روی درگاههای ارتباط با مشتری چقدر سرمایه در نظر گرفتهاید؟ وقتی صحبت از سرمایه میشود مقصود، فقط خرج کردن پول نقد نیست، تخصیص نیروی انسانی و وقت گذاشتن برای شکلدادن و بهبود مستمر درگاههای ارتباطی خود بزرگترین سرمایهگذاری است و برگ برندهی بسیاری از سازمانهای موفق است.
طبق نظرسنجیی که برگزارشده امروزه ایمیل و پورتال سلفسرویس (درگاه خودخدمتی) متداولترین روش برای دسترسی به خدمات فناوری اطلاعات و دریافت پشتیبانی نسبت به تماس تلفنی است، در میان سازمانهای بررسی شده:
بیش از ۸۴٪ سازمانها از ایمیل برای ارایهی خدمات استفاده میکنند، ۸۲٪ پورتال سلف سرویس و 76٪ تلفن.
www.MedaNet.ir
سنجش موفقیت سلفسرویس فناوری اطلاعات
نتایجی که باعث شده پورتال سلفسرویس موفقیت چندانی نداشته باشد ازنظر کارشناسان فناوری اطلاعات بدین نحو گزارششده:
18 درصد از سازمانها میزان استفاده از پورتال سلفسرویس IT را اندازهگیری نمیکنند
41 درصد از سازمانها از معیارهای کمی مانند حجم استفاده از آن فقط بهره گرفتهاند.
21 درصد از سازمانها از معیارهای کیفی فوری مانند بازخورد کارکنان استفاده میکنند
18 درصد از سازمانها از معیارهای کیفی دورهای مانند بازخورد عمومی کاربران استفاده میکنند
گسترش پورتالهای سلفسرویس فناوری اطلاعات خارج از فناوری اطلاعات
این نظرسنجی نشان داد که 29٪ از سازمانها پورتال سلفسرویس فناوری اطلاعات خود را حداقل به یک کار تجاری دیگر گسترش ندادهاند
برنامههای بهبود سلفسرویس فناوری اطلاعات
مهمترین اقدامات برای بهبود درگاه سلفسرویس عبارتند از: ایجاد مکانیسم خدمات و پشتیبانی خودکار، خودکارسازی سازی، اطلاعرسانی دقیق و زمانبندیشده، پاسخگویی خودکار و هوشمند، ارتباط مبتنی بر صدا، چت. نظرسنجی، نمودارهای استفاده کاربران و انتظار آنان در صف درخواست، تولید راهکارهای آموزشی و ایجاد سطح دسترسی به سایر سامانههای سازمانی.
www.MedaNet.ir
نتایجی که باعث شده پورتال سلفسرویس موفقیت چندانی نداشته باشد ازنظر کارشناسان فناوری اطلاعات بدین نحو گزارششده:
18 درصد از سازمانها میزان استفاده از پورتال سلفسرویس IT را اندازهگیری نمیکنند
41 درصد از سازمانها از معیارهای کمی مانند حجم استفاده از آن فقط بهره گرفتهاند.
21 درصد از سازمانها از معیارهای کیفی فوری مانند بازخورد کارکنان استفاده میکنند
18 درصد از سازمانها از معیارهای کیفی دورهای مانند بازخورد عمومی کاربران استفاده میکنند
گسترش پورتالهای سلفسرویس فناوری اطلاعات خارج از فناوری اطلاعات
این نظرسنجی نشان داد که 29٪ از سازمانها پورتال سلفسرویس فناوری اطلاعات خود را حداقل به یک کار تجاری دیگر گسترش ندادهاند
برنامههای بهبود سلفسرویس فناوری اطلاعات
مهمترین اقدامات برای بهبود درگاه سلفسرویس عبارتند از: ایجاد مکانیسم خدمات و پشتیبانی خودکار، خودکارسازی سازی، اطلاعرسانی دقیق و زمانبندیشده، پاسخگویی خودکار و هوشمند، ارتباط مبتنی بر صدا، چت. نظرسنجی، نمودارهای استفاده کاربران و انتظار آنان در صف درخواست، تولید راهکارهای آموزشی و ایجاد سطح دسترسی به سایر سامانههای سازمانی.
www.MedaNet.ir
زمان توقف سرویس یا DownTime
یکی از ارکان کلیدی در برنامهریزی تغییرات، تعیین مدت زمان توقف سرویس است. چقدر باید زمان بگذاریم برای یک تغییر کوچک یا جزئی؟
در سناریوهایی که داریم معمولاً انجام یک تغییر جزئی، زمان چندانی را نمیطلبد. فرض کنید پورت وب یک سرویس را تغییر دادیم و برای مشاهده تغییر انجام شده نیاز به ریست کردن سرور داریم. حداکثر ظرف ۵ دقیقه این مورد قابل انجام است بنابراین مجری به کارفرما این مدت زمان را اعلام میکند که البته بسیار نادرست است.
--------------
در هنگام تعیین زمانبندی توقف سرویس موارد زیر را در نظر داشته باشید:
• زمان انجام تغییر
• زمان ریستور کردن سرویس به حالت پیش از تغییر در هنگام شکست تغییر
• زمان تلف شده ناشی از سایر پیامدهای غیرقابل پیشبینی حین اجرای کار
این را در نظر داشته باشید که همیشه نتایج تغییرات مطلوب نیست. بسیار پیش میآید که مشکلی حادث میشود که نیاز به بازگشت به نقطهی اول هستید. این یعنی برای تغییر پورت فلان سرویس اگر ۵ دقیقه زمان نیاز دارید به این زمانبندی، حدود ۱۵ دقیقه بابت ریستور کردن سرویس (بکاپ) به حالت پیش از تغییر هم اضافه کنید همچنین زمانی را نیز برای برخی پیامدهای ناشی از عوامل غیرقابل پیشبینی حین کار تخصیص دهید. به زبان سادهتر یک تغییر جزئی در بهترین حالت ۱ ساعت توقف سرویس نیاز دارد.
این یک زمانبندی با لحاظ کردن تمام جوانب است. بنابراین اگر تغییر، موفقیتآمیز انجام شود شما همان ۵ دقیقه را صرف کردهاید و اگر ناموفق باشد و حدود ۶۰ دقیقه طول بکشد زیر سوال نمیروید!
--------------
البته این نکته را یادآور شوم که هرچقدر این زمانبندی بیش از این مقدار باشد ریسک تغییر بالا خواهد رفت. این موضوع در تغییرات استاندارد و عمده، قطعاً زمان بیشتری را در بر خواهد گرفت.
لابد میپرسید پس آزمایشگاه و طرحهای برنامهریزی تغییر پیش از اجرا، در اینجا چه نقشی دارند!؟
در پاسخ باید گفت که همیشه محیط عملیاتی با محیط شبیهسازی شده و آزمایشی متفاوت است اگرچه با چنین محیطی میتوان از وقوع بسیاری از پیامدهای محتمل جلوگیری کرد اما قطعیت ندارد. بنابراین در تنظیم زمان توقف سرویس، کمی دستتان را بالا بگیرید.
www.MedaNet.ir
یکی از ارکان کلیدی در برنامهریزی تغییرات، تعیین مدت زمان توقف سرویس است. چقدر باید زمان بگذاریم برای یک تغییر کوچک یا جزئی؟
در سناریوهایی که داریم معمولاً انجام یک تغییر جزئی، زمان چندانی را نمیطلبد. فرض کنید پورت وب یک سرویس را تغییر دادیم و برای مشاهده تغییر انجام شده نیاز به ریست کردن سرور داریم. حداکثر ظرف ۵ دقیقه این مورد قابل انجام است بنابراین مجری به کارفرما این مدت زمان را اعلام میکند که البته بسیار نادرست است.
--------------
در هنگام تعیین زمانبندی توقف سرویس موارد زیر را در نظر داشته باشید:
• زمان انجام تغییر
• زمان ریستور کردن سرویس به حالت پیش از تغییر در هنگام شکست تغییر
• زمان تلف شده ناشی از سایر پیامدهای غیرقابل پیشبینی حین اجرای کار
این را در نظر داشته باشید که همیشه نتایج تغییرات مطلوب نیست. بسیار پیش میآید که مشکلی حادث میشود که نیاز به بازگشت به نقطهی اول هستید. این یعنی برای تغییر پورت فلان سرویس اگر ۵ دقیقه زمان نیاز دارید به این زمانبندی، حدود ۱۵ دقیقه بابت ریستور کردن سرویس (بکاپ) به حالت پیش از تغییر هم اضافه کنید همچنین زمانی را نیز برای برخی پیامدهای ناشی از عوامل غیرقابل پیشبینی حین کار تخصیص دهید. به زبان سادهتر یک تغییر جزئی در بهترین حالت ۱ ساعت توقف سرویس نیاز دارد.
این یک زمانبندی با لحاظ کردن تمام جوانب است. بنابراین اگر تغییر، موفقیتآمیز انجام شود شما همان ۵ دقیقه را صرف کردهاید و اگر ناموفق باشد و حدود ۶۰ دقیقه طول بکشد زیر سوال نمیروید!
--------------
البته این نکته را یادآور شوم که هرچقدر این زمانبندی بیش از این مقدار باشد ریسک تغییر بالا خواهد رفت. این موضوع در تغییرات استاندارد و عمده، قطعاً زمان بیشتری را در بر خواهد گرفت.
لابد میپرسید پس آزمایشگاه و طرحهای برنامهریزی تغییر پیش از اجرا، در اینجا چه نقشی دارند!؟
در پاسخ باید گفت که همیشه محیط عملیاتی با محیط شبیهسازی شده و آزمایشی متفاوت است اگرچه با چنین محیطی میتوان از وقوع بسیاری از پیامدهای محتمل جلوگیری کرد اما قطعیت ندارد. بنابراین در تنظیم زمان توقف سرویس، کمی دستتان را بالا بگیرید.
www.MedaNet.ir
👍1
عقبنشینی!
برعکس ما که، اگر خطایی بکنیم نمیتوانیم آن را از حافظهی تاریخی خود و مردم پاک کنیم، کامپیوترها به لطف مفاهیمی نظیر: کلیدهای Ctrl+Z و Backup ، Restore Point، Back out ، Roll Outو... قادر به بازگشت به نقطهی پیش از خطا هستند.
در برنامهریزی تغییرات، بسیار پیش میآید که آن تغییر ممکن است نتایج مورد انتظار ما را تامین نکند. در چنین شرایطی باید برنامهای برای عقبنشینی به نقطهی صفر یا همان نقطهی پیش از انجام تغییر در نظر داشته باشیم وگرنه اجرای یک تغییر ناموفق و بدون برنامهی بازگشت یا Back Plan میتواند فاجعه بار باشد و هزینه و ارزش منفی زیادی را به سازمان تحمیل کند.
بحث برنامهی بازگشت، از ملاکهای ارزیابی ریسک تغییر در مدیریت تغییر است. این یعنی هر تغییری که برنامهی بازگشت نداشته باشد ریسک بالاتری دارد. حتی گاهاً نیاز هست برنامههای بازگشت چند پلهای طراحی کرد نظیر آنچه که برنامهنویسان برای عیبیابی یک سورس کد برنامه ازش استفاده میکنند.
فراموش نباید کرد که ماهیت هر تغییری آغشته به ریسک است. اما این بدان معنا نیست که چون تغییر، ریسک دارد پس انجامش ندهیم بلکه باید ریسک آن را با تمهیدات مهندسی شده به حداقل برسانیم!
www.MedaNet.ir
برعکس ما که، اگر خطایی بکنیم نمیتوانیم آن را از حافظهی تاریخی خود و مردم پاک کنیم، کامپیوترها به لطف مفاهیمی نظیر: کلیدهای Ctrl+Z و Backup ، Restore Point، Back out ، Roll Outو... قادر به بازگشت به نقطهی پیش از خطا هستند.
در برنامهریزی تغییرات، بسیار پیش میآید که آن تغییر ممکن است نتایج مورد انتظار ما را تامین نکند. در چنین شرایطی باید برنامهای برای عقبنشینی به نقطهی صفر یا همان نقطهی پیش از انجام تغییر در نظر داشته باشیم وگرنه اجرای یک تغییر ناموفق و بدون برنامهی بازگشت یا Back Plan میتواند فاجعه بار باشد و هزینه و ارزش منفی زیادی را به سازمان تحمیل کند.
بحث برنامهی بازگشت، از ملاکهای ارزیابی ریسک تغییر در مدیریت تغییر است. این یعنی هر تغییری که برنامهی بازگشت نداشته باشد ریسک بالاتری دارد. حتی گاهاً نیاز هست برنامههای بازگشت چند پلهای طراحی کرد نظیر آنچه که برنامهنویسان برای عیبیابی یک سورس کد برنامه ازش استفاده میکنند.
فراموش نباید کرد که ماهیت هر تغییری آغشته به ریسک است. اما این بدان معنا نیست که چون تغییر، ریسک دارد پس انجامش ندهیم بلکه باید ریسک آن را با تمهیدات مهندسی شده به حداقل برسانیم!
www.MedaNet.ir
Forwarded from [ K a z i o ]
مشتریان کازیو به 10.000 نفر رسید...!
از اعتمادی که میکنید بینهایت قدردانیم. شما فقط حامی کازیو نشدید، بلکه حامی موسسه کودکان سرطانی محک شدید و حامی نجات درخت!
نشر دیجیتال کازیو، دستبوس همراهی شماست....
www.Kazio.ir
از اعتمادی که میکنید بینهایت قدردانیم. شما فقط حامی کازیو نشدید، بلکه حامی موسسه کودکان سرطانی محک شدید و حامی نجات درخت!
نشر دیجیتال کازیو، دستبوس همراهی شماست....
www.Kazio.ir
قلم پیکربندی!
قلم پیکربندی یا CI که اختصار Configuration Item است در حقیقت یک جزء از دیتابیس مدیریت پیکربندی است که از آن برای شناسایی، کنترل، حسابرسی و مدیریت روابطش با سایر اقلام پیکربندی استفاده میشود. در مدیریت خدمات، هر قلم، یک دستهبندی برای تعریف موجودیتهای منحصر و یکتاست که در ارائهی محصول یا خدمت مورداستفاده قرار میگیرد. به زبان سادهتر هر چیزی که در ارائهی محصول یا خدمت مؤثر است تحت لوای یک CI تعریف میشود.
از دیدگاه مجری یک تغییر، CI عبارت است از «چه اقلامی» متأثر از انجام یک تغییر میشوند. این یعنی زمانی که یک تغییر را قرار است انجام دهیم چه CI-های تحت تأثیر این تغییر واقع میشوند. قلم پیکربندی حاوی یک کد یکتا و دارای اطلاعات پیکربندی و سرشار از روابط مستقیم یا معکوس است. داشتن روابط سبب میشود تا ردیابی و حسابرسی آن سریعتر ممکن شود.
به این مثال توجه کنید: یک جلسهی آنلاین آموزشی نیازمند اقلام پیکربندی زیر است:
· افراد (مدرس و دانشجویان)
· نرمافزار ویدئوکنفرانس
· وب کم یا دوربین
· میکروفن
· کامپیوتر
· اتاق جلسات
برای ارائهی خدمت آموزش، وجود هرکدام از این اقلام ضروری است. بدیهی است در صورت ایجاد اخلال و یا نبود هرکدام از آنها جلسهی آموزشی با مشکل مواجهه خواهد شد و البته هر تغییری میتواند روی هرکدام از این اقلام نیز اثر بگذارد بهطور مثال تغییر مدرس یا تغییر نرمافزار ویدئوکنفرانس جزو تغییراتی هستند که خدمت آموزش را تحت تأثیر خود قرار خواهد داد.
اقلام پیکربندی عبارتاند از:
· سختافزار/دستگاهها
· نرمافزار/برنامههای کاربردی
· ارتباطات/شبکهها
· مکانها
· مستندات
· امکانات
· پایگاه داده
· سرویسها و...
هر قلم پیکربندی حاوی صفات و خواصی است که رایجترین آنها شامل:
1. شناسه یا کد شناسایی منحصربهفرد CI
2. نام یا برچسب CI
3. توضیحات CI
4. مالکیت CI (سازمانها و افراد)
5. تأثیر و اهمیت CI
6. ریز مشخصات پیکربندی قلم
اقلام پیکربندی جزو لاینفکی از مدیریت خدمات هستند. شناسایی، پیکربندی و کنترل و مدیریت آنها به همراه مشاهدهی نقشهی روابط بین اقلام، دید وسیعی را در مورد اهمیت آن ها به شما خواهد داد؛ که سبب بهبود در ارایهی خدمات میشود.
www.Servicedeskplus.ir
قلم پیکربندی یا CI که اختصار Configuration Item است در حقیقت یک جزء از دیتابیس مدیریت پیکربندی است که از آن برای شناسایی، کنترل، حسابرسی و مدیریت روابطش با سایر اقلام پیکربندی استفاده میشود. در مدیریت خدمات، هر قلم، یک دستهبندی برای تعریف موجودیتهای منحصر و یکتاست که در ارائهی محصول یا خدمت مورداستفاده قرار میگیرد. به زبان سادهتر هر چیزی که در ارائهی محصول یا خدمت مؤثر است تحت لوای یک CI تعریف میشود.
از دیدگاه مجری یک تغییر، CI عبارت است از «چه اقلامی» متأثر از انجام یک تغییر میشوند. این یعنی زمانی که یک تغییر را قرار است انجام دهیم چه CI-های تحت تأثیر این تغییر واقع میشوند. قلم پیکربندی حاوی یک کد یکتا و دارای اطلاعات پیکربندی و سرشار از روابط مستقیم یا معکوس است. داشتن روابط سبب میشود تا ردیابی و حسابرسی آن سریعتر ممکن شود.
به این مثال توجه کنید: یک جلسهی آنلاین آموزشی نیازمند اقلام پیکربندی زیر است:
· افراد (مدرس و دانشجویان)
· نرمافزار ویدئوکنفرانس
· وب کم یا دوربین
· میکروفن
· کامپیوتر
· اتاق جلسات
برای ارائهی خدمت آموزش، وجود هرکدام از این اقلام ضروری است. بدیهی است در صورت ایجاد اخلال و یا نبود هرکدام از آنها جلسهی آموزشی با مشکل مواجهه خواهد شد و البته هر تغییری میتواند روی هرکدام از این اقلام نیز اثر بگذارد بهطور مثال تغییر مدرس یا تغییر نرمافزار ویدئوکنفرانس جزو تغییراتی هستند که خدمت آموزش را تحت تأثیر خود قرار خواهد داد.
اقلام پیکربندی عبارتاند از:
· سختافزار/دستگاهها
· نرمافزار/برنامههای کاربردی
· ارتباطات/شبکهها
· مکانها
· مستندات
· امکانات
· پایگاه داده
· سرویسها و...
هر قلم پیکربندی حاوی صفات و خواصی است که رایجترین آنها شامل:
1. شناسه یا کد شناسایی منحصربهفرد CI
2. نام یا برچسب CI
3. توضیحات CI
4. مالکیت CI (سازمانها و افراد)
5. تأثیر و اهمیت CI
6. ریز مشخصات پیکربندی قلم
اقلام پیکربندی جزو لاینفکی از مدیریت خدمات هستند. شناسایی، پیکربندی و کنترل و مدیریت آنها به همراه مشاهدهی نقشهی روابط بین اقلام، دید وسیعی را در مورد اهمیت آن ها به شما خواهد داد؛ که سبب بهبود در ارایهی خدمات میشود.
www.Servicedeskplus.ir
دیتاشیت سرویس دسک پلاس
سرویس دسک پلاس یک نرمافزار بینالمللی، تحت وب و محبوب برای مدیریت خدمات است. که با تجهیز شدن به ماژول ESM امکان مدیریت تمام خدمات سازمانی را بر پایهی چارچوب ITIL میسر میکند این یعنی تمام واحدهای خدماتی سازمان میتوانند از یک بستر واحد و مشابه برای ارایهی خدمات خود استفاده کنند: ESM کار بزرگی است قطعاً تا زمانی که خود فناوری اطلاعات از این بستر به نحو احسن استفاده نکند نمیتواند واحدهای دیگر را برای استفاده از آن تعمیم دهد. مهمترین علت عدم استفادهی کامل از این سرویس، ناشی از عدم شناخت تمام امکانات و ویژگیهای آنست. از لینک زیر با قابلیتهای منحصرش آشنا شوید و این سرویس را برای تمام سازمان پیادهسازی کنید و لذت ببرید:
https://lnkd.in/eny5nMJV
سرویس دسک پلاس یک نرمافزار بینالمللی، تحت وب و محبوب برای مدیریت خدمات است. که با تجهیز شدن به ماژول ESM امکان مدیریت تمام خدمات سازمانی را بر پایهی چارچوب ITIL میسر میکند این یعنی تمام واحدهای خدماتی سازمان میتوانند از یک بستر واحد و مشابه برای ارایهی خدمات خود استفاده کنند: ESM کار بزرگی است قطعاً تا زمانی که خود فناوری اطلاعات از این بستر به نحو احسن استفاده نکند نمیتواند واحدهای دیگر را برای استفاده از آن تعمیم دهد. مهمترین علت عدم استفادهی کامل از این سرویس، ناشی از عدم شناخت تمام امکانات و ویژگیهای آنست. از لینک زیر با قابلیتهای منحصرش آشنا شوید و این سرویس را برای تمام سازمان پیادهسازی کنید و لذت ببرید:
https://lnkd.in/eny5nMJV
Forwarded from [ S o r o u s h a n e ]
نتایج یک شاخص عملکرد!
برای اندازهگیری عملکرد کارکنان فناوری اطلاعات ۲۳ شاخص تهیه کردم. که یکی از آنها اشتراکگذاری اطلاعات و تجربیات بر اساس تمرین مدیریت راهکار بود. مدیر فناوری آن سازمان هم کیفور بود که با این شاخصها میتواند افراد را تخلیهی اطلاعاتی کند. هرچند نیّت من بهبود بود، نیّت او سهولت در جایگزینی افراد. خواستهی من زوم کردن افراد روی تواناییهایشان برای کسب تجربیات جدید بود و خواستهی او زیر ذرهبین گذاشتن کمبودهای آنان.
----
نتیجه: هیچکس هیچچیزی را برای دیگران به اشتراک نگذاشت.
علت:
1. ترس از جایگزینی با علم به نیّت آن مدیر
2. نبود امنیت شغلی
3. ضعف دارندهی آن تجربه
راهکارهایی که پیشنهاد کردم:
1. دادن پاداش نقدی به ازای تولید هر راهکار کاربردی تائید شده
2. اعطایی مسئولیت جدید به فرد ارائهکنندهی تمام تجربیات مسئولیت فعلی(ولو با یک وعدهی موقتی)
3. اذعان مکتوب مدیر فناوری اطلاعات به عذرخواهی بابت داشتن نیّت نادرست(ولو به تظاهر)
-----
نتیجه برای مدیر: همه تخلیهی اطلاعات شدند!
نتیجه برای من: اثری از سیلوهای اختصاصی تجربیات دیگر نبود همه از چندوچون تجربیات همدیگر آگاه بودند و کارها با سرعت و کیفیت بیشتری انجام میگرفت و آنان به سوی بهبود و کشف تواناییهای خود میرفتند.
نتیجه برای کارکنان: پول خوبی گیرشان آمد اما ترسشان باقی ماند با این تفاوت زیبا که: قبلاً برای از دست ندادن موقعیت شغلی، تجربیات را به اشتراک نمیگذاشتند، اکنون برای حفظ موقعیت شغلی در تلاش برای کسب تجربیات جدید بودند!
#ITIL #Solution_Management
www.Soroushane.ir
برای اندازهگیری عملکرد کارکنان فناوری اطلاعات ۲۳ شاخص تهیه کردم. که یکی از آنها اشتراکگذاری اطلاعات و تجربیات بر اساس تمرین مدیریت راهکار بود. مدیر فناوری آن سازمان هم کیفور بود که با این شاخصها میتواند افراد را تخلیهی اطلاعاتی کند. هرچند نیّت من بهبود بود، نیّت او سهولت در جایگزینی افراد. خواستهی من زوم کردن افراد روی تواناییهایشان برای کسب تجربیات جدید بود و خواستهی او زیر ذرهبین گذاشتن کمبودهای آنان.
----
نتیجه: هیچکس هیچچیزی را برای دیگران به اشتراک نگذاشت.
علت:
1. ترس از جایگزینی با علم به نیّت آن مدیر
2. نبود امنیت شغلی
3. ضعف دارندهی آن تجربه
راهکارهایی که پیشنهاد کردم:
1. دادن پاداش نقدی به ازای تولید هر راهکار کاربردی تائید شده
2. اعطایی مسئولیت جدید به فرد ارائهکنندهی تمام تجربیات مسئولیت فعلی(ولو با یک وعدهی موقتی)
3. اذعان مکتوب مدیر فناوری اطلاعات به عذرخواهی بابت داشتن نیّت نادرست(ولو به تظاهر)
-----
نتیجه برای مدیر: همه تخلیهی اطلاعات شدند!
نتیجه برای من: اثری از سیلوهای اختصاصی تجربیات دیگر نبود همه از چندوچون تجربیات همدیگر آگاه بودند و کارها با سرعت و کیفیت بیشتری انجام میگرفت و آنان به سوی بهبود و کشف تواناییهای خود میرفتند.
نتیجه برای کارکنان: پول خوبی گیرشان آمد اما ترسشان باقی ماند با این تفاوت زیبا که: قبلاً برای از دست ندادن موقعیت شغلی، تجربیات را به اشتراک نمیگذاشتند، اکنون برای حفظ موقعیت شغلی در تلاش برای کسب تجربیات جدید بودند!
#ITIL #Solution_Management
www.Soroushane.ir
Forwarded from [ S o r o u s h a n e ]
آنتروپی مدیریت تغییر!
هر چقدر فشار برای اعمال تغییر بیشتر شود، مقاومت برای اجرا نشدن تغییر نیز بیشتر میشود. این آنتروپی تغییر است.
زیرا منطق آدمها در زمان فشار، تابآوری کمی دارد و در برابر تغییری که قرارست با شدت تحمیل شود، با هر چیزی در دست و ذهن داشته باشند برای اجرا نشدن تغییر اقدام میکنند. راهکار ساده این است که تنش ایجاد نکنید. بهزور نچپانید! آرام و آسوده در بازههای زمانی مورد توافق گروه پیشاهنگ تغییر، شروع به اجرای ذره به ذرهی تغییر بکنید.
هدف ما اجرای تغییر نیست. هدف فقط تغییر کردن نیست، هدف نتیجهی تغییر است. دنبال نتیجه باشید نه عنوان تغییر!
www.Soroushane.ir
--------
#itil #changemanagement
هر چقدر فشار برای اعمال تغییر بیشتر شود، مقاومت برای اجرا نشدن تغییر نیز بیشتر میشود. این آنتروپی تغییر است.
زیرا منطق آدمها در زمان فشار، تابآوری کمی دارد و در برابر تغییری که قرارست با شدت تحمیل شود، با هر چیزی در دست و ذهن داشته باشند برای اجرا نشدن تغییر اقدام میکنند. راهکار ساده این است که تنش ایجاد نکنید. بهزور نچپانید! آرام و آسوده در بازههای زمانی مورد توافق گروه پیشاهنگ تغییر، شروع به اجرای ذره به ذرهی تغییر بکنید.
هدف ما اجرای تغییر نیست. هدف فقط تغییر کردن نیست، هدف نتیجهی تغییر است. دنبال نتیجه باشید نه عنوان تغییر!
www.Soroushane.ir
--------
#itil #changemanagement
استفاده از ITSM بهعنوان یک پلتفرم رقابتی
یکی از یافته های جالب از نظرسنجی Forbes Insights این بود که استقرار ITSM علاوه بر کاهش هزینه فناوری اطلاعات، مزایای رقابتی دیگری نیز به همراه می آورد. وقتی پرسیده شد: "سازمان شما چه مزیتی را در نتیجه استفاده از ITSM بدست آوردهاید؟" (نتایج زیر)،
· 40٪ صرفه جویی هزینه ها در فرآیندهای کسب و کار
· 48٪ افزایش بهره وری کارکنان
· 49٪ صرفه جویی در هزینه سیستم های IT
· 25٪ پاسخ سریعتر به مشتریان / کاربر نهایی
· 14٪ زمان سریعتر برای رسیدن کالاها و خدمات به بازار
www.MedaNet.ir
یکی از یافته های جالب از نظرسنجی Forbes Insights این بود که استقرار ITSM علاوه بر کاهش هزینه فناوری اطلاعات، مزایای رقابتی دیگری نیز به همراه می آورد. وقتی پرسیده شد: "سازمان شما چه مزیتی را در نتیجه استفاده از ITSM بدست آوردهاید؟" (نتایج زیر)،
· 40٪ صرفه جویی هزینه ها در فرآیندهای کسب و کار
· 48٪ افزایش بهره وری کارکنان
· 49٪ صرفه جویی در هزینه سیستم های IT
· 25٪ پاسخ سریعتر به مشتریان / کاربر نهایی
· 14٪ زمان سریعتر برای رسیدن کالاها و خدمات به بازار
www.MedaNet.ir
چارچوب ITIL برای همه! [کارشناسان NOC]
پندار غلطی که هست اینست که ITIL و ابزار پیادهسازی آن فقط برای کارشناسان پشتیبانی کاربران است!
این چیزی است که کارشناسان شبکه میگویند زیرا درگیر کانفیگ سوییچ و روتر و ارتباطات زیرساختند و خود را جدای از بحث سیستم مدیریت خدمات فناوری اطلاعات میبییند. اما مانیتورینگ شبکه بدون کنترل نرخ مشکلات، فقط سرپا نگهداشتن زیرساخت شبکه است آنهم فقط برای امروز!
هدف کارشناسان عملیات شبکه NOC این نیست که چشم روی وضعیت سرورها و ارتباطات بگذارند و هر خرابی را رفع رجوع کنند هدف این است که مشکلات، نفوذها و عواملی که سبب وقوع چنین پیامدهایی میشوند را شناسایی و در جهت رفع ریشهای آن اقدام کنند.
بنابراین زیرساخت شبکه از مبحث چارچوب ITIL جدا نیست و آنان با استفاده از ITIL قادر به گردآوری اطلاعات دقیق راجع به حجم و تبدیل Event-ها به Incident-ها، بررسی نرخ مشکلات ریشهای و اجرای پروژهها خواهند بود و جهت این مهم به شدت نیازمند ابزار ITIL هستند. اما فقط این نیست حجم عظیمی از تغییرات، توسط کارشناسان عملیات شبکه صورت میگیرد و اینان هستند که باعث بروز بیشتر خرابیها میشوند زیرا بیشتر تغییرات اعمال شده بدون ارزیابی ریسک و بدون برنامهریزی بوده. پس مدیریت رویداد، مدیریت رخداد، مدیریت درخواست، مدیریت مشکل، مدیریت تغییر و مدیریت داراییها و خریدها و قراردادها جزو لاینفکی از نیازمندی کارشناسان NOC و دیتاسنتر است.
کارشناسان NOC بیشتر از هر کسی به سرویس دسک نیاز دارند!
www.MedaNet.ir
#itil #itom #eventmanagement #incidentmanagement #problemmanagement #changemanagement
پندار غلطی که هست اینست که ITIL و ابزار پیادهسازی آن فقط برای کارشناسان پشتیبانی کاربران است!
این چیزی است که کارشناسان شبکه میگویند زیرا درگیر کانفیگ سوییچ و روتر و ارتباطات زیرساختند و خود را جدای از بحث سیستم مدیریت خدمات فناوری اطلاعات میبییند. اما مانیتورینگ شبکه بدون کنترل نرخ مشکلات، فقط سرپا نگهداشتن زیرساخت شبکه است آنهم فقط برای امروز!
هدف کارشناسان عملیات شبکه NOC این نیست که چشم روی وضعیت سرورها و ارتباطات بگذارند و هر خرابی را رفع رجوع کنند هدف این است که مشکلات، نفوذها و عواملی که سبب وقوع چنین پیامدهایی میشوند را شناسایی و در جهت رفع ریشهای آن اقدام کنند.
بنابراین زیرساخت شبکه از مبحث چارچوب ITIL جدا نیست و آنان با استفاده از ITIL قادر به گردآوری اطلاعات دقیق راجع به حجم و تبدیل Event-ها به Incident-ها، بررسی نرخ مشکلات ریشهای و اجرای پروژهها خواهند بود و جهت این مهم به شدت نیازمند ابزار ITIL هستند. اما فقط این نیست حجم عظیمی از تغییرات، توسط کارشناسان عملیات شبکه صورت میگیرد و اینان هستند که باعث بروز بیشتر خرابیها میشوند زیرا بیشتر تغییرات اعمال شده بدون ارزیابی ریسک و بدون برنامهریزی بوده. پس مدیریت رویداد، مدیریت رخداد، مدیریت درخواست، مدیریت مشکل، مدیریت تغییر و مدیریت داراییها و خریدها و قراردادها جزو لاینفکی از نیازمندی کارشناسان NOC و دیتاسنتر است.
کارشناسان NOC بیشتر از هر کسی به سرویس دسک نیاز دارند!
www.MedaNet.ir
#itil #itom #eventmanagement #incidentmanagement #problemmanagement #changemanagement
چارچوب ITIL برای همه! [کارشناسان توسعهی نرمافزار]
برنامهنویسان و تیم توسعه نرمافزاری به دلیل درگیر شدن با محیطهای برنامهنویسی و باگتریگرها معمولاً دلخوشی نسبت به چارچوب ITIL ندارند و اینان نیز شبیه کارشناسان NOC این چارچوب و ابزار ITIL را مناسب کارشناسان پشتیبانی کاربران میدانند. این تفکر غلط دلایل بسیاری دارد. آنان نمیخواهند بطور مهندسی شده تغییرات لازم در تولیدات خود را بر اساس مدیریت تغییر و نشر پیش ببرند.
دلیل مخالفت آنان، عدم درک درست ITIL است زیرا بدون ارزیابی درست و برای شانه خالی کردن از زیر بار رفتن آن، بهانههایی نظیر دست و پا گیر بودن تمرینات ITIL میآورد در حالیکه هدف ITIL تسریع و بهبود در ارایهی خدمت است چه آن خدمت زیرساخت باشد چه تولید و توسعهی نرمافزار. از این رو نه تنها چارچوب ITIL برای برنامهنویسان و تیم توسعه است بلکه از آن به شکل بسیار مناسبی در جهت توسعهی فعالیتهای خود میتوانند استفاده کنند.
این کمک میکند تا نرخ تغییرات ناآگاهانه در برنامهی توسعه نرمافزار به حداقل برسد. فرایند انتشار به بهترین وجه و با کمترین سعی و خطا صورت گیرد. داراییهای مرتبط با یک نرمافزار را کنترل و تاثیر تغییرات بر آنها را اندازه بگیرند. پروژههای نرمافزاری خلق کنند و به تفکیک وظایف هر بخش از توسعه، یک یا چند فاز یا کار را بین اعضای تیم توزیع کنند. پس مدیریت رویداد، مدیریت رخداد، مدیریت درخواست، مدیریت مشکل، مدیریت تغییر، مدیریت نشر و مدیریت داراییها و خریدها و قراردادها جزو لاینفکی از نیازمندی کارشناسان نرمافزار است. کارشناسان تیم توسعه بیشتر از هر کسی به سرویس دسک نیاز دارند!
www.MedaNet.ir
#itil #releasemanagement #itsm #incidentmanagement #problemmanagement #changemanagement
برنامهنویسان و تیم توسعه نرمافزاری به دلیل درگیر شدن با محیطهای برنامهنویسی و باگتریگرها معمولاً دلخوشی نسبت به چارچوب ITIL ندارند و اینان نیز شبیه کارشناسان NOC این چارچوب و ابزار ITIL را مناسب کارشناسان پشتیبانی کاربران میدانند. این تفکر غلط دلایل بسیاری دارد. آنان نمیخواهند بطور مهندسی شده تغییرات لازم در تولیدات خود را بر اساس مدیریت تغییر و نشر پیش ببرند.
دلیل مخالفت آنان، عدم درک درست ITIL است زیرا بدون ارزیابی درست و برای شانه خالی کردن از زیر بار رفتن آن، بهانههایی نظیر دست و پا گیر بودن تمرینات ITIL میآورد در حالیکه هدف ITIL تسریع و بهبود در ارایهی خدمت است چه آن خدمت زیرساخت باشد چه تولید و توسعهی نرمافزار. از این رو نه تنها چارچوب ITIL برای برنامهنویسان و تیم توسعه است بلکه از آن به شکل بسیار مناسبی در جهت توسعهی فعالیتهای خود میتوانند استفاده کنند.
این کمک میکند تا نرخ تغییرات ناآگاهانه در برنامهی توسعه نرمافزار به حداقل برسد. فرایند انتشار به بهترین وجه و با کمترین سعی و خطا صورت گیرد. داراییهای مرتبط با یک نرمافزار را کنترل و تاثیر تغییرات بر آنها را اندازه بگیرند. پروژههای نرمافزاری خلق کنند و به تفکیک وظایف هر بخش از توسعه، یک یا چند فاز یا کار را بین اعضای تیم توزیع کنند. پس مدیریت رویداد، مدیریت رخداد، مدیریت درخواست، مدیریت مشکل، مدیریت تغییر، مدیریت نشر و مدیریت داراییها و خریدها و قراردادها جزو لاینفکی از نیازمندی کارشناسان نرمافزار است. کارشناسان تیم توسعه بیشتر از هر کسی به سرویس دسک نیاز دارند!
www.MedaNet.ir
#itil #releasemanagement #itsm #incidentmanagement #problemmanagement #changemanagement