IRAN ITIL --- ITSM

يادداشت‌هاي گروه ما درباره پياده سازي در يك سازمان دولتي

انتقال به آدرس جدید
ساعت ۱٢:٠۸ ‎ب.ظ روز ٢۱ آذر ۱۳۸٧  

با سلام به همه دوستان علاقه مند

از این پس شما میتوانید مطالب را از طریق آدرس پایین پیگیری کنید. از این پس فقط این آدرس به روز خواهد شد.

 

www.iranitil.com

 

itsm، مدیریت سطح سرویس، problem management، best practice، incident management، change management، cmdb، مفاهیم پایه ای مدیریت، مدیریت سرویس،ccta، help desk، software asset management، sla، ishikawa diagram، ticket، incident tracking، rfc، fsc، service strategy، service design، service transition، service operation، ُservice، service catalog، itil business plan، exin، iseb، ci، configuration management، service desk، مدیریت درخواست سرویس، مدیریت تغییرات، مدیریت مشکلات،

ema، itup، iso/iec 20000


کلمات کلیدی: itil ،itsm ،incident management ،best practice
 
پاسخ به ده سوال اصلی ITIL (سوال هفتم و هشتم)
ساعت ۱:٤۱ ‎ب.ظ روز ۸ آذر ۱۳۸٧  

7- من چه سطحی از آموزش را نیاز دارم؟
موقعیت شما در سازمان کجاست؟ اگر شما تلاش میکنید که یک برنامه اصلی ITSM را راهبری کنید، نیاز دارید که در سطح حرفه ای (Expert Level) مدرک بگیرید. این نمای کاملتری از ITIL را به شما خواهد داد. اگر شما یک اجرا کننده هستید که علاقه دارید به سادگی آگاهی بیشتری از ITIL پیدا کنید، ما کلیات اجرایی (Executive Overview) را به شما پیشنهاد میکنیم. به عنوان یک مدیر یا عضو تیم پروژه که در خلال پیاده سازی یک best practice خاص کار میکند، EMA آموزش پایه ای (foundation) را پیشنهاد میکند.

8- در یک سازمان آموزشی باید چه چیزی را جستجو کنیم؟
شما باید مطمئن شوید که هر آموزش دهنده باید برای آزمونها، با EXIN یا ISEB کار کند. تمام مدارک ITIL توسط این دو بورد امتحانی در ترکیب با OGC و Forum مدیریت سرویس IT (itSMF) مدیریت میشود که هیئت مدیریت مدرک ITIL (ICMB) را در بر دارد.


کلمات کلیدی: exin ،itil ،best practice ،iseb
 
پاسخ به ده سوال اصلی ITIL (سوال پنجم و ششم)
ساعت ۱۱:٥۳ ‎ق.ظ روز ۱ آذر ۱۳۸٧  

5-    در سازمان ما در حال حاضز نسخه 2 از ITIL پیاده سازی شده است. آیا ما واقعا به این نیاز داریم که نسخه 3 را بیاموزیم؟
برخی مفاهیم جدید در نسخه 3 از ITIL معرفی شده که این مفاهیم به خاطر تشخیص دادن اشکالات نسخه 2 افزوده شده است. از آنجاییکه موارد
پایه ای از نسخه 2 هنوز در نسخه 3 موجود است، این احساس به وجود می آید که علاوه بر چیزهای آموخته شده در نسخه 2 میتوان از مزایای نسخه 3 نیز برخوردار شد. شما میتوانید از خودتان بپرسید که : "ما چگونه CMDB یا Service Catalog (فهرست سرویس) را در آینده میبینیم؟" مدیریت Service catalog به عنوان best practice خودش در ITIL نسخه 3 شناخته شده. این همچنین ناحیه ای از ITIL است که میتواند یک تاثیر دراماتیک روی ارتباط با مشتریها داشته باشد. پایگاه داده مدیریت پیکربندی (CMDB) هم برخی تغییرات پایه ای داشته است. ITIL  نسخه 2 فقط با یک CMDB  در ارتباط است. ITIL نسخه 3 مشخص میکند که چه EMA ای بلندترین پشتیبانی را در روی تمارین مشاوره ای ما دارد – چندین CMDB مستقل با یک CMDB مرکزی به عنوان هسته (core)، هماهنگی، یکپارچگی، همزمانی و سرویسهای اصلاح را مهیا میکند.



6-    چه کسی واقعا نیاز دارد که آموزش ببیند و در چه سطحی باید آموزش ببیند؟
نه تمام افراد سازمان شما نیاز دارند که در سطح پایه ای (foundation level) مدرک بگیرند و نه تمام مدیران شما نیاز دارند که مدرک حرفه ای ITIL را بگیرند. در خلال ارزیابیها ما به کمپانیها این کمک را میکنیم که به این سوال پاسخ بدهند. ما به این نتیجه رسیدیم که باید پرسنل پروژه ای داشته باشیم که آموزشهای پایه ای ITIL را دیده باشند. مدیران ارشد میتوانند از پیاده سازی کلی ITIL و انجام workshop که مفاهیم پایه ای برای پیاده سازی و پیشبرد ITIL Business Plan در آن آموزش داده میشود، سود ببرند.


کلمات کلیدی: itil ،service catalog ،cmdb ،itil business plan
 
پاسخ به ده سوال اصلی ITIL (سوال سوم و چهارم)
ساعت ۱٢:۳٥ ‎ب.ظ روز ۱٧ آبان ۱۳۸٧  

3- سازمان ما باید چه مقدار بزرگ باشد تا به ITIL نیاز داشته باشیم؟
ITIL فقط مختص سازمانهای بزرگ نیست. فرآیندهایی که توسط ITIL حمایت میشوند یک framework برای مدیریت تمامی سازمانهای IT میباشد. مادامی که شما این را درک نکردید که برای سازمان شما مناسب است که هر ابزار مدیریتی را پیاده سازی و رواج دهید، شما باید تمام best practice ها را ارزیابی کنید و معین کنید که کدام یک از آنها برای سازمان شما مناسبتر است. توصیه ما این است که نقاط درد و مشکل را تعقیب کنید. تشخیص دهید که چه چیزی بیشترین محصول را برای درو به شما میدهد.

4- چرا باید ITIL را بیاموزیم؟
آیا ما نمیتوانیم فقط کتابها را بخوانیم؟ این واقعا نادر است که ما بتوانیم به صورت شخصی و بدون کمک در یک سازمان کامل و با تکیه بر خواندن یک کتاب و آموختن مفاهیم آن را به کار ببریم. مادامیکه به صورت حاشیه ای موفق باشید، احتمال اینکه شما مشکلات را بیشتر از آنکه حل کنید، آنها را بسازید وجود دارد. EMA برخی آموزشها در سطوح پایه ای مختلف را برای سازمان شما پیشنهاد میکند. به سوال شماره 6 که در ادامه خواهد آمد توجه کنید.

شما همچنین خواهید دید که سازمانتان از استانداردسازی عبارات و درک کلی مفاهیم ارائه شده در آموزش ITIL سود خواهد برد.


 
پاسخ به ده سوال اصلی ITIL (سوال اول و دوم)
ساعت ۱٢:٢٧ ‎ب.ظ روز ۱٧ آبان ۱۳۸٧  

یکی از موارد ثابت IT تغییر است. پس تغییر در ITIL نباید باعث غافلگیری ما بشود. نسخه دوم ITIL در سال 2000 منتشر شد، و پارسال هم برخی تغییرات مهم در نسخه 3 آورده شد. با هر تغییر معمولا افراد دچار سوالهای مختلف میشوند. در این بخش به 10 سوال متداول که بین افراد متخصص پرسیده میشود پاسخ داده میشود.


1- ITIL چیست؟
ITIL مخفف عبارت Information Technology Infrastructure Library است. این مفهوم توسط دفتر بازرگانی دولت در انگلستان ساخته شد و شامل منتخبی از بهترین شیوه ها (best practice) برای مدیریت IT میباشد. این شامل 5 جلد کتاب مجزای اصلی میباشد. این کتب چرخه زندگی (lifecycle) IT را به صورت کامل به ما میشناساند و شامل اطلاعاتی در رابطه با مفاهیم پایه ای مدیریت در IT مانند مدیریت تغییرات (Change MAnagement)، فهرست سرویس (Service Catalog) و پایگاه داده مدیریت پیکربندی (CMDB) میباشد.

2- رقبای ما با ITIL چه میکنند؟
شانسهایی هستند، آنها در حال کامل کردن آموزش ITIL هستند و در حال پیاده سازی خیلی از مفاهیم و best practice های یافت شده در ITIL میباشند. در یک بررسی جدید روی پیاده سازیهای فهرست سرویس، بیش از 90 درصد از سرویس دهنده ها مطابق ITIL آموزش دیده اند صرف نظر از اینکه آیا آنها آیا تصمیم گرفته اند که فهرست سرویس را پیاده سازی کنند.


 
www.iranitil.com
ساعت ٩:٥٧ ‎ق.ظ روز ۱ آبان ۱۳۸٧  

باید به همه دوستان علاقه مند این مژده را بدهم که از این پس میتوانید با آدرس زیر راحتتر به ما دسترسی پیدا کنید:

 

http://www.iranitil.com


کلمات کلیدی: itil ،itsm ،مدیریت سرویس ،help desk
 
اصطلاحات مربوط به مدیریت تغییرات
ساعت ٩:٥٢ ‎ق.ظ روز ۱ آبان ۱۳۸٧  

تغییر : افزودن، تغییر دادن و یا حذف CI ها
درخواست برای تغییر(RFC): فرم مصرف شده برای ثبت جزئیات درخواست برای یک تغییر که به عنوان یک ورودی برای مدیریت تغییرات از طرف درخواست کننده تغییرات ارسال میشود.
زمانبندی پیشرو از تغییرات (FSC): زمانبندی که شامل جزئیات تمامی تغییرات در شرف انجام میباشد.


کلمات کلیدی: itil ،change management ،rfc ،fsc
 
درباره Help Desk
ساعت ۱:٥٢ ‎ب.ظ روز ٢۱ مهر ۱۳۸٧  

Help desk  یک منبع اطلاعاتی و کمکی  است که مشکلات را با استفاده از کامپیوتر رفع می کند . شرکت ها غالبا پشتیبانی Help desk را برای مشتریان بوسیله شماره تلفن رایگان ، وب سایت و یا پست الکترونیک فراهم  می کنند . همچنین Help desk های در محل ( در خانه ) نیز برای کارمندان وجود دارد . تعدادی از مدارس کلاس هایی را برای انجام اعمالی مشابه ، مثل Help desk  برگزار کرده اند . درInformation Technology Infrastructure Library شرکت هایی که مایل به اخذ ISO/IEC 20000 و یا پیاده سازی IT Service Managementهستند ، Help desk می تواند یک سرویس دهی متمرکز را فراهم کرده و زمینه های پیوستن به یک Service Desk بزرگتر فراهم نماید .

طرز کار

 یک سیستم HelpDesk به چند روش عمل می کند . این سیستم یک نقطه مرکزی برای دریافت کمک در کتمپیوتر های مختلف فراهم می کند . HelpDesk ها ، درخواست هایشان را توسط برنامه ی Help desk مدیریت می کنند ، مانند Incident Tracking System ، که اجازه می دهد تا درخواست کاربران با یک شماره منحصربفرد پیگیری شود . همچنین به این سیستم Local Bug Tracker هم اطلاق می شود . هنگامیکه در محیط سازمانی به جستجو ،‌تحلیل و ارزیابی مشکلات عمومی می پردازیم ، یک سیستم Help Desk می تواند بسیار مفید باشد . 
کاربر مشکلش را در برنامه وارد کرده و برنامه به او یک شماره بلیط ( Ticket Number ) می دهد که حاوی جزئیات مشکل مطرح شده وی است . اگر اولین گروه از پشتیبان ها بتوانند مشکل را برطرف نمایند ، مشکل برطرف شده و بسته ( Close ) می شود و راه حل برطرف کردن مشکل در تیکت ( Ticket ، بلیط ) برای مراجعات بعدی کارکنان پشتیبانی در تیکت نوشته می شود . اما درصورتی که گروه اول پتیبانی قادر به حل مشکل نبود تیکت توسط آنها بروز شده و برای حل به گروه دوم پشتیبانی ارجاع داده می شود .
برنامه ( نرم افزار ) های زیادی برای HelpDesk وجود دارند ، برخی از آنها برای سازمان های بزرگ ( Enterprise ) طراحی شده اند و برخی دیگر برای سازمانهای کوچک تر  .
در تحقیقی که در میانه ی دهه ی نود میلادی توسط Middleton در The Robert Gordon University انجام شد ،‌ مشخص شد که بسیاری از سازمانها به ارزش واقعی Helpdesk پی برده و به استفاده از Help Desk روی آورده اند ، نه به این علت که این برنامه ها یک کد پیگیری منحصربفرد تولید می کنند ، بلکه به این سبب که تمام درخواست های متقاضیان از یک نقطه مشترک بین درخواست دهنده و کارکنان پشتیبانی قابل پیگیری است .

سازمان

 Help desk های بزرگ سطوح مختلفی برای پاسخ دهی به درخواست های مختلف را دارند . Help desk های سطح یک یا First-Level Help desk برای پاسخ دهی به پرسش های عمومی و یا فراهم کردن یک پایگاه دانش یا FAQ ایجاد شده اند . بطور عمومی یک Incident Tracking System برای مواقعی که تعداد بسیاز زیادی تماس گرفته می شود پیاده سازی شده است . اگر مشکل ( Issue ) در مرحله اول ( First-Level ) حل نشد ، مقیاس تیکت بزرگ شده و به مرحله بعدی ( دوم ) ، که نیازمندی های برطرف کردن یک مشکل جدی تر را داراست می رود . همچنین توجه داشته باشید که سازمانها دارای یک سطح بالاتر ( سطح سوم ) هستند که معمولا به نیازهای نرم افزاری ارتباط دارد ، مانند update ها و bug-fix ها که بر روی مشتری ها تاثیر گذار است .
Help Desk های بزرگ معمولا یک شخص یا تیم مسئول برای مدیریت تیکت ها دارند که به آن ( ها ) مدیران صف ها ( Queue Managers ) و یا سرپرست صف ها ( Queue Supervisors ) اطلاق می شود ، مدیر تیکت ، مسئول رسیدگی به صف های تیکت ها است ، که می تواند از روش های مختلفی انجام ود که بسته به اندازه و قابلیت ها و ساختار برنامه Help Desk دارد . بطور کلی Help Desk های بزرگ دارای تیم های مختلف پشتیبانی هستند که هر تیم تجربه کار بر روی Issue های مختلفی را داراست . مدیر صف ها ، تیکت را بسته به درخواست دریافت شده و تخصص تیم های پشتیبانی بین صف های مختلف پخش می کند . برخی از Help Desk  ها دارای سیستم تلفنی با ACD Splits هستند که برای اطمینان از ورود درخواست رسیده و ثبت آن ، برای مراجعات بعدی بکار برده می شوند .
بعضی از Help Desk ها در مواقع بحرانی کاربرد دارند ( ‌برای مواقع بحرانی ایجاد شده اند ) . زمان برای تحلیل یا انجام و پیگیری مشکل ، تماس و درخواست رسیده از پست الکترونیک بسیار کم است . یک Roster System تضمین می کند که زمان کافی برای پیگیری مشکلات ، تماس ها و … وجود دارد و همیشه شخصی برای پاسخگویی به تماس ها در واحد پشتیبانی وجود دارد . از آنجا که زمان تماس های تلفنی ذاتا نامشخص است ، پاسخگوی Help desk بصورت گردشی تعویض می شود .

تیم پای میز ( Deskside Team )

تیم پای میز ( بعضی اوقات با نام “پشتیبان پای میز” - Desktop Support - شناخته می شود ) مسئول Desktop ها ، لپ تاب ها و وسیل جانبی ، مانند PDA ها است . Help Desk ها معمولا هنگامی از این گروه برای حل مشکل استفاده می کنند که پشتیبان های سطح اول قادر به رفع مشکل نباشند . آنها کامپیوترها را برای کاربران جدید تنظیم و پیکربندی می کنند و معمولا مسئول مشکلات فیزیکی پیش آمده برای کامپیوترها مانند برطرف کردن مشکل برنامه ها یا سخت افزارها و نیز جابجا کردن کامپیوترها از جایی به جای دیگر هستند .

 تیم شبکه ( Network Team )

تیم شبکه مسئول نرم افزارها و سخت افزارها و ابزارهایی مانند سرورها ، سوئیچ ها ،‌سیستم های پشتیبانی گیری ( ‌Backup systems ) و فایروال شبکه است . آنها مسئول سرویس های شبکه مانند پست الکترونیک ،‌ فایل ها و امنیت هستند . Help Desk درخواست های رسیده ی مرتبط را برای این تیم ارسال می کند .

تیم های دیگر

برخی شرکت ها یک تیم مخابرات ( Telecom Team ) هستند که مسئول رسیدگی به ابزار مرتبط با تلفن مانند PBX , VoiceMail , VOIP و تلفن و مودم و دستگاه فکس و تجهیزاتی از این قبیل هستند ، آنها مسئول پیکربندی و جابجایی خطوط تلفن ، تنظیم کردن و پیکربندی VoiceMail و HelpDesk این فبیل درخواست ها را به این واحد نسبت می دهد .
شرکت هایی که دارای برنامه های سفارشی هستند ، دارای یک تیم برنامه ( Application Team ) هستند ، که مسئول توسعه نرم افزار هستند . HelpDesk درخواست هایی از قبیل Bug های نرم افزاری و درخواست قابلیت جدید در برنامه و بهبود عملکرد برنامه را به این تیم ارسال می کند .

 

توجه داشته باشید که تمامی کارکنان HelpDesk و IT در یک محل مشترک قرار ندارند . با برنامه های راه دور ( Remote Access Applications ) تکنسین ها قادرند بسیاری از مشکلات را از راه دور رفع مشکل نمایند . برای مشکلات در-محل ( on-site ) نیاز به رفتن تکنسین به محل وجود دارد . هر چند که HelpDesk ها با برنامه های راه دور می توانند برخی از مشکلات را رفع کنند .



کلمات کلیدی: itil ،help desk ،ticket ،incident tracking
 
مدیریت تغییرات (Change Management)
ساعت ٧:٠۱ ‎ب.ظ روز ٢٠ مهر ۱۳۸٧  

هدف مدیریت تغییرات این است که مطمئن شود که متدها و روشهای استاندارد شده برای اداره کردن موثر تمام تغییرات استفاده شود، برای اینکه تاثیرات سوء رخدادهای حاصل از تغییرات حداقل شده و برای اینکه عملیات روز به روز بهبود یابد.
یک تغییر معادل است با “یک رویداد که باعث یک یا چند وضعیت جدید در آیتمهای پیکربندی(CI) شود”. اهداف اصلی مدیریت تغییرات موارد زیر است :

  1. حداقل کردن قطع سرویسها
  2. کاهش فعالیتهای فرسوده شده
  3. بکارگیری اقتصادی از منابع درگیر با تغییرات

کلمات کلیدی: مدیریت تغییرات ،itil ،change management ،ci
 
ادامه مباحث مدیریت مشکلات
ساعت ٢:٤٥ ‎ب.ظ روز ٧ مهر ۱۳۸٧  

فرآیند مدیریت مشکل این هدف را دارد که تعداد و شدت رخدادها و مشکلات را روی تجارت کاهش دهد و آن را در قالب مستندات گزارش داده تا در اولین و دومین مورد در help desk در دسترس باشد. فرآیند پیش گیرانه، مشکلات را قبل از اینکه رخدادی روی دهد تعیین کرده و آنها را حل میکند. این فعالیتها به شرح زیر است :

  •  تحلیل روند
  • عملیات پشتیبانی هدف
  • جمع آوری اطلاعات برای سازمان

 فرآیند کنترل خطا یک فرآیند تکراریست تا خطاهای شناخته شده را تشخیص دهد تا اینکه آنها با پیاده سازی موفق یک تغییر در کنترل فرآیند مدیریت تغییرات حل شود. فرآیند کنترل مشکل فصد دارد که مشکلات را در یک راه موثر و کارا کنترل کند. این فرآیند علت ریشه ای (root cause) رخدادها را مشخص کرده و آنها را به service desk معرفی میکند. دیگر فعالیتها عبارت است از :

  • شناسایی مشکل و ثبت آن
  • دسته بندی مشکلات
  • بررسی و تشخیص مشکل

تکنیک استاندارد برای مشخص کردن ریشه اصلی مشکل این است که از یک دیاگرام Ishikawa استفاده کنید، همچنین مراجعه کنید به نمودار علت و معلول (cause and effect diagram)، نمودار درخت (tree diagram)، یا نمودار جناغی (fish diagram). نمودار ایشیکاوا نتیجه نوعی از جلسه طوفان مغزی است که در آن اعضای یک گروه ایده های خود را برای بهبود یک محصول مطرح مینمایند. برای حل مشکل، هدف پیدا کردن دلیل و تاثیرات یک مشکل است. نمودار ایشیکاوا میتواند در یک meta-model تعریف شود. اولا یک موضوع اصلی موجود است، که ما تلاش میکنیم که کدام backbone از نمودار را حل کنیم یا بهبود ببخشیم. موضوع اصلی از یک علت مشتق میشود. ارتباط بین یک علت و یک اثر یک ارتباط دوطرفه است: یک اثر نتیجه یک دلیل و علت است، و یک علت ریشه یک اثر است. اما فقط یک اثر برای چندین علت موجود است و یک دلیل برای چندین اثر موجود است.


کلمات کلیدی: itil ،problem management ،help desk ،ishikawa diagram