جزئیات ساختار ITIL v2 - بخش دوم « پشتیبانی سرویس -2- مدیریت رخداد »

جزئیات ساختار ITIL v2 - بخش اول « پشتیبانی سرویس -1- مدیریت درخواست سرویس »

2. مدیریت رخداد - IcM - Incident Management

هدف مدیریت رخداد ، بازگرداندن عملیات سرویس دهی به شکل معمول و نرمال ، در کمترین زمان ممکن و به حداقل رساندن اثرگذاری مضرات ( ناسازگاری ها )‌در عملیات تجاری است . بنابراین تضمین می شود که بهترین سطوح کیفیت سرویس و در دسترس بودنِ ( Availability ) ممکن ، ‌برقرار می باشد . ٰ عملیات معمول سرویس ( Normal Service Operation ) ٰ در اینجا به عنوان یک عملیات سرویس در محدودیت های توافق‌نامه سطح سرویس ( SLA ) تعریف می شود .

به زبان دیگر مدیریت رخداد ( IcM ) یک بخش فرآیند از مدیریت سرویس فن‌آوری اطلاعات ( ITSM - IT Service Management ) است . هدف اول این فرآیند ، بازگرداندن عملیات به شکل سرویس دهی طبیعی و نرمال در کمترین زمان ممکن و به حداقل رسانیدن تاثیرات منفی آن (‌عدم سرویس دهی ) در عملیات تجاری است . بنابراین بهترین کیفیت عملیات سرویس ممکن و موجودی‌ها را تضمین می کند . ٰ سرویس دهی نرمال ٰ به شکل یک بند از عملیات سرویس در توافق‌نامه سطح سرویس ( SLA ) بیان می شود .

مشکل رخدادهایی که توسط برنامه سریعا رفع نمی شوند ، به یک گروه پشتیبانی مخصوص، جهت رفع مشکل ، نسبت داده می شود . به منظور بازگرداندن سریع سرویس دهی نرمال ، مشکل باید سریعا توسط این گروه برطرف شود .

تعریف

فرهنگ لغات ITIL رخداد ( Incident ) را به این شکل تعریف می کند :

هر رخدادی که جزیی از یک عملیات استاندارد سرویس نیست و به بروز وقفه یا کاهش کیفیت سرویس دهی منجر شده یا می شود.

هدف ITIL رسیدن به عملیات عادی و طبیعی در کمترین و کوتاه ترین زمان ممکن ، با کمترین میزان تاثیر در تجارت یا کاربر ، با صرف یک هزینه مقرون به صرفه است . رخدادها ممکن است به دلایل مشخص و یا نامشخصی به وقوع بپیوندند ونهایتا به منظور کنترل کردن مدیریت مشکلات ( problem management ) در Known Error Database - KeDB ثبت می‌شوند.

در جایی که محیط ‍پیرامون کارِ از پ‍یش تعریف شده , توسعه پیدا کرده است , پیشنهاد می‌شود که service desk یک محیط سریع را برای برطرف کردن مشکل, در اولین مرحله فراهم کند .

در جایی که یک رخداد نتیجه یک مشکل شناخته شده و یا خطای شناخته شده نباشد, می‌تواند یک محیط ایزوله شده یا یک پیش آمد منحصر بفرد یا ممکن است که مشکل ریشه ای مشخص شده باشد , نیاز است که مدیریت مشکلات درگیر شود , در صورت امکان باید یک مشکل جدید, با مشخصات رخداد ایجاد شود.

رخدادها و تغییرات

رخدادها نتایج مشکلات و خطاهای زیربناهای فن‌آوری اطلاعات هستند. علت بروز رخداد ممکن است پیدا و روشن باشد و نیازی به سرمایه گذاری ( از نظر زمانی و هزینه‌ای ) برای شناسایی علت بروز رخداد نباشد و منجر به درخواست برای یک تعمیر , یک حضور فیزیکی در محل یا یک درخواست تغییر برای حذف خطا باشد .

جایی که یک رخداد مطرح می‌شود تا بصورت جدی و قاطعانه پیگیری شود, و یا چند پیشامد مشابه یک رخداد مشاهده می‌شود , یک مشکل می‌تواند به عنوان پاسخی برای حل همه موارد در سیستم ثبت شود ( همچنین ممکن است تا چند مشکل مشابه گزارش نشد, اصلا مشکلی هم ثبت نشود ). مدیریت یک مشکل از فرآیند مدیریت یک رخداد ( می تواند ) متفاوت است و معمولا توسط کارمندان متفاوت انجام می‌شود و به همین دلیل توسط فرآیند مدیریت مشکلات کنترل می‌شود. وقتی که یک مشکل شناسایی می‌شود و محیط مشکل پیدا می‌شود , مشکل یک ‍ ٰمشکل شناخته شدهٰ می شود. هنگامیکه ریشه و علت بروز رخداد شناسایی می شود تبدیل به یک ٰخطای شناسایی شدهٰ می شود و نهایتا یک درخواست تغییر ( Request For Change - RFC ) ممکن است برای تغییر ( اصلاح ) سیستم با رفع خطای شناسایی شده ایجاد شود. این فرآیند توسط فرایند مدیریت تغییرات ( Change Management ) تحت پوشش قرار گرفته است.

توجه داشته باشید که درخواست یک سرویس اضافی به عنوان یک رخداد شناخته نمی شود و آن را یک درخواست تغییر ( RFC ) می نامند .

فرآیند مدیریت رخداد

فرآیندهای اصلی مدیریت رخداد در زیر آورده شده‌اند :

• شناسایی و ثبت رخداد - Incident detection and recording


• طبقه بندی و پشتیبانی اولیه - Classification and initial support


• تحقیق و تشخیص - Investigation and diagnosis


• رفع مشکل و بازیابی - Resolution and recovery


• بستن رخداد - Incident closure


• مالکیت رخداد , بازدید, پیگیری و ارتباطات - Incident ownership, monitoring, tracking and communication

مثال و نمونه

رخدادها باید طبقه بندی بشوند همانطور که ثبت می شوند, نمونه های برای طبقه بندی رخدادها در زیر آورده شده است :

• Application
  
  
  
  • service not available
  
  
  • application bug
  
  
  • disk-usage threshold exceeded
  
  
  
  


• Hardware
  
  
  
  • system-down
  
  
  • automatic alert
  
  
  • printer not printing
  
  
  
  

منابع :‌

• Incident management


• Incident Management - ITSM


• ITIL

جزئیات ساختار ITIL v2 - بخش اول « پشتیبانی سرویس -1- مدیریت درخواست سرویس »

پشتیبانی سرویس ( Service Support )

نظام پشتیبانی سرویس ITIL بر روی کاربر سرویس ICT متمرکز شده است و وظیفه اصلی آن تضمین دسترسی آنها به سرویس‌های مورد نظر ، به منظور پشتیبانی وظایف تجاری است .

برای یک تجارت ، مشتری ها و کاربران نقاط ورودی به مدل فرآیند ( Process Model ) هستند . آنها ( مشتری ها و کاربران ) بوسیله :

• درخواست تغییرات ( Asking for Changes )


• لزوم ارتباطات ، بروز راسنی‌ها ( Needing Comminucation , Updates )


• درگیر شدن ، پرس و جو ( Having Difficulties , Queries )

درگیر پشتیبانی سرویس می شوند . برنامه Service desk تنها نقطه ارتباطی مشتریان برای مطرح کردن مشکلاتشان می باشد . که درصورت وجود پاسخ ، مشکل برطرف می شود و در غیر این صورت یک رخداد ( Incident ) ثبت می شود . رخداد باعث بوجود آمدن یک سری فرآیند می شود : مدیریت رخداد ( Incident Management ) , مدیریت مشکلات ( Problem Management) , مدیریت تغییرات ( Change Management ) , مدیریت نسخه های منتشر شده و مدیریت پیکربندی ( Release Management and Configuration Management ) . این سری فرآیندها توسط پایگاه داده مدیریت پیکربندی ( Configuration Management Database - CMDB ) پیگیری و ثبت می شود . که هر فرآیند را ذخیره می کند و مستنداتی را برای امکان پذیر کردن پیگیری تولید می کند ( مدیریت کیفیت - Quality Management )‌.

1. مدیریت درخواست سرویس ( Service Desk / Service Request Management )

وظایف ServiceDesk ، رسیدگی به رخدادها و درخواست‌ها می باشد و یک واسط برای سایر فرآیندهای مدیریت سرویس فن‌آوری اطلاعات ( ITSM ) فراهم می کند.

• تنها نقطه ارتباط ( SPOC - Single Point of Contact ) و نه لزوما اولین نقطه ارتباط ( FPOC - First Point of Contact ) .


• تنها یک نقطه ارتباطی ورود و خروج وجود دارد


• سهولت استفاده برای مشتری ها


• یکپارچگی داده ها


• کانال ارتباطی سریع ، مفید ، موثر و پرکاربرد است

وظایف اصلی یک ServiceDesk عبارتند از :

• کنترل رخدادها :‌ مدیریت چرخه زندگی تمامی درخواست های سرویس


• ارتباطات : مطلع کردن مشتری ها از وضعیت رسیدگی به درخواست ها و پاسخ دهی به آنها

وظایف ServiceDesk تحت عناوین مختلفی شناخته می شود

1. Call Center ( مرکز تماس ) : تاکید اصلی بر روی رسیدگی به پاسخگویی به تعداد بسیار زیادی از تماس های تلفنی است .


2. Help Desk ( پیش‌خوان کمک و یاری [ برنامه پشتیبانی ]) : مدیریت ، هماهنگی ، رسیدگی و رفع مشکلات مربوط به رخدادها در سریع ترین زمان ممکن .


3. Service Desk ( پیش‌خوان سرویس ) : فقط به رخدادها ، مشکلات و پرسش ها رسیدگی نمی کند ، بلکه علاوه اینها یک واسط برای سایر فعالیت ها مانند درخواست‌های تغییر ، قراردادهای نگهداری ، مجوزهای نرم افزار ( Software Licenses ) ، مدیریت سطح سرویس ( Service Level Management ) ، مدیریت پیکربندی ( Configuration Management ) ، مدیریت موجودی ( Availability Management ) ، مدیریت مالی ( Financial Management ) و مدیریت بهبود مداوم سرویس‌های فن‌اوری اطلاعات ( IT Services Continuity Management ) فراهم می کند .

سه نوع ساختاری که برای ServiceDesk می توان به آنها اشاره کرد عبارتند از :

1. Local Service Desk ( داخلی ) : برای برطرف کردن نیازهای تجاری محلی - فقط تا زمانی یک ابزار تمرینی است که در چندین محل درخواست سرویس داشته باشند .


2. Central Service Desk ( مرکزی ) : برای برطرف کرذن نیاز موسساتی که دارای چندین محل هستند - هزینه های عملیاتی را پایین آورده و به کارگیری منابع موجود را بهبود می بخشد .


3. Virtual Service Desk ( مجازی ) : برای برطرف کردن نیاز سازمان هایی که در چند کشور قرار گرفته اند - می تواند با بهره گیری از مزایای بهبود شبکه و مخابرات ،از هر نقطه ای در جهان مورد دسترسی قرار بگیرد . و منجر به کاهش هزینه های عملیاتی و بهبود بکارگیری منابع موجود شود .

کلیاتی از کتابخانه ITIL v3

ITIL v3 در ماه may ( خرداد ) 2007 منتشر شد و شامل پنج جلد کلیدی ( key volumes ) است :
استراتژی سرویس ( Service Strategy )
طراحی سرویس ( Service Design )
انتقال سرویس ( Service Transition )
عملیات سرویس ( Service Operation )
بهبود مداوم سرویس ( Continual Service Improvement )
1. استراتژی سرویس ( Service Strategy )
استراتژی سرویس در مرکز ( هسته ) چرخه زندگی ITIL v3.1 قرار گرفته اما نمی تواند به تنهایی و بدون سایر بخش های ساختار IT ایجاد شود . این بخش دربرگیرنده یک framework ( ‌زیربنا ) برای ایجاد تجربیات موفق ( best practices ) در اثر توسعه بلند مدت استراتژی سرویس است . این بخش شامل موضوعات مختلفی مانند :
استراتژی عمومی ( General Strategy )
رقابت و فضای بازار ( Competition and Market Space )
انواع فراهم کنندگان سرویس ( Service Provider Types )
مدیریت سرویس در نقش دارایی استراتژیک ( Service Management as a Strategic Asset )
طراحی و توسعه سازمان ( Organization Design and Development )
فعالیت های کلیدی فرآیندها ( Key Process Activities )
مدیریت مالی ( Financial Management )
مدیریت سرویس سهام ( Service Portfolio Management )
و نقش های کلیدی و مسئولیت های کارکنان درگیر در استراتژی سرویس ( Key Roles and Responsibilities of Staff engaging in Service Strategy )
می باشد .
2. طراحی سرویس ( Service Design )
طراحی سرویس IT از تجربیات موفق ( Best Practice ) تبعیت می کند و شامل طراحی معماری ( Design of Architecture ) ، فرآیندها ، قوانین ( Policies ) ، مستندات و درنظر گرفتن نیازمندی های تجاری آینده است . این بخش همچنین شامل موضوعاتی مانند ،
بسته طراحی سرویس ( SDP - Service Design Package )
مدیریت سرویس فهرست ( Service Catalog Management )
مدیریت سطح سرویس ( Service Level Management )
طراحی برای مدیریت گنجایش ( Designing for Capacity Management )
سرویس IT مداوم ( IT Service Continuity )
امنیت اطلاعات ( Information Security )
مدیریت ملزومات ( Supplier management )
و نقش های کلیدی و مسئولیت کارکنان درگیر در طراحی سرویس ( key roles and responsibilities for staff engaging in service design )
می باشد .
3. انتقال سرویس ( Service Transition )
انتقال سرویس به تحویل سرویس هایی مربوط می شود که نیاز تجاری فعال / عملیاتی ( Live\Operational use ) دارند . و اغلب از بخش “پروژه” IT پیروی می کنند بجای تجارت مرسوم ( BAU - Business as Usual ) . این بخش همچنین موضوعاتی از قبیل :
مدیریت تغییرات در محیطهای تجارت مرسوم ( Managing changes to the “BAU” environment )
دارایی سرویس ( Service Asset )
مدیریت پیکربندی ( Configuration Management )
برنامه ریزی و پشتیبانی انتقال ( Transition Planning and Support )
مدیریت توسعه و نسخه ( Release and Deployment Management )
مدیریت تغییرات ( Change Management )
مدیریت دانش ( Knoweledge Management )
نقش های کلیدی کارکنان درگیر در انتقال سرویس ( Key Roles of Staff engaging in Service Transition )
را شامل می شود .
4. عملیات سرویس ( Service Operation )
تجربه موفق در گروی نائل شدن به تحویل سطوح مورد پذیرش ( agreed levels ) سرویس ها ، برای هردوی کاربران نهایی و مشتری هاست ( که “مشتری” به کسی گفته می شود که برای دریافت یک سرویس بهایی را پرداخت کرده باشند و در مورد ، توافق نامه سطح سرویس ( SLA’s - Service Level Agreement ) گفتگو کرده باشند ) . عملیات سرویس بخشی از چرخه زندگی است ، وقتی که سرویس ها و مقادیر ( value ) کاملا تحویل شده اند . همچنین ردگیری ( Monitoring ) مشکلات ( Problems ) و برقراری تعادل بین سرویس اطمینان بخش ( Service reliability ) و هزینه و غیره قابل ذکر و توجه است . موضوعات شامل :
برقراری تعادل بین اهداف برخوردی ، مانند اطمینان و هزینه و … ( Balancing Confilicting Goals )
مدیریت رخدادها ( Event Management )
مدیریت وقایع ( Incident Management )
مدیریت مشکلات ( Problem Management )
تکمیل رخدادها ( Event Fulfillment )
مدیریت دارایی ها ( Asset Management )
سرویس خدمات ( Service Desk )
مدیریت برنامه و تکنیکی ( Technical and Application Management )
نقش های کلیدی و مسئولیت کارکنان درگیر در عملیات سرویس ( key roles and responsibilities for staff engaging in Service Operation )
می شوند .
5. بهبود مداوم سرویس ( CSI - Continual Service Improvement )
5.1 شرح کوتاه
مرتب سازی و مرتب سازی دوباره سرویس های IT به منظور تغییر نیازهای تجاری انجام می شود ( به آن دلیل که ثبات ، باعث رو به زوال رفتن موسسه و یا تنزل آن می شود).هدف بهبود مداوم سرویس ،‌ مرتب سازی و مرتب سازی دوباره سرویس های IT ، برای تغییر نیازهای تجاری ، بوسیله تعریف و پیاده سازی بهبودها در سرویس های IT یی است که فرآیند تجاری را پشتیبانی می کنند . دورنمای بهبود مداوم سرویس در بهبودها ، دورنمای تجاری کیفیت سرویس است ، حتی با اینکه بهبود مداوم سرویس ، می خواهد تاثیرات فرآیندها ، بازدهی و هزینه موثر فرآیندهای IT را در تمامی طول چرخه حیاتشان بهبود ببخشد . بر اساس بهبود مدیریت ، بهبود مداوم سرویس باید بصورت کاملا روشن و واضح ، تعریف کند که چه چیزی باید کنترل و اندازه گیری شود .
بهبود مداوم سرویس باید مانند سایر تجربیات موفق عمل شود . آنها نیازمند یک برنامه ریزی بالا به پیش رو ( upfront ) ، آموزش و اطلاع رسانی ، زمان بندی مداوم ، ایجاد نقش ها ، نسبت دادن به خود ، و فعالیت ها براساس میزان موفقیت شناسایی می شوند . بهبود مداوم سرویس باید مانند فرآیندها با فعالیت های تعریف شده ، ورودی ها ، خروجی ها ، نقش ها و گزارش ها برنامه ریزی و زمان بندی شود .
5.2 شرح کامل
مادامی که موسسه در حال شناسایی سرویس هایش است ( اینکه چه سرویس هایی دارد ) ، همچنین فرآیند توسعه و پیاده سازی مدیریت سرویس فن آوری اطلاعات ( ITSM - IT Service Management ) آن سرویس ها را قابل استفاده می نماید ، بسیاری بر این باورند که کار مشکل انجام شده است . آنها سخت در اشتباهند !!! کار واقعی تازه آغاز شده است . موسسات چگونه برای استفاده فرآیند جدید درگیر می شوند ( چگونه بر اساس فرآیند جدید کار می کنند ) ؟ موسسات چگونه می سنجند ، گزارش می گیرند و از اطلاعات برای بهبود نه تنها فرآیند های جدید بلکه بهبود مداوم سرویس های مهیا شده اقدام می کنند ؟ این کار مستلزم یک بحث خردمندانه برای آداپته کردن بهبود مداوم سرویس با ورودی ها ، خروجی ها و نقش های تعریف شده و مسئولیت ها و اهدافی است که بطور واضح تعریف شده اند و رویه هایی است که مستند شده اند ، می باشد . برای موفقیت ، بهبود مداوم سرویس باید با فرهنگ هر سازمان سازگار و بومی ( embed ) شود .
چرخه حیات سرویس یک معبر وسیع به مدیریت سرویس ( Service Management ) است : برای درک ساختار آن ، ارتباط مابین تمامی اجزای آن ، و اینکه چگونه تغییر در هر منطقه ( یا جایی ) بر روی تمامی سیستم و بخش های تشکیل دهنده ( که از آن به بعد ایجاد می شوند ) تاثیر گذار خواهد بود ، یک زیربنا و شالوده ( Framework ) سازمان یافته برای کارایی بهتر و قابل تحمل طراحی شده است .
چرخه حیات سرویس می تواند در یک قالب گرافیکی نمایش داده شود ، که در این حالت مقادیر را به راحتی می توان در دو شکل ” همکاری تجاری ( Business Contribution ) ” و ” سود و منافع ( Profit ) ” نشان داد . همکاری تجاری ، بیانگر توانایی یک سازمان IT برای پشتیبانی از یک فرآیند تجاری و مدیریت سرویس های IT با میزان کارایی درخواست شده است . سود و منافع ، بیانگر توانایی مدیریت هزینه های سرویس در ارتباط با درآمدهای تجاری است .
چرخه حیات سرویس را می توان مانند یک چرخه حیات فازبندی شده نمایش داد ، که این فازها عبارتند از :
تعریف استراتژی برای مدیریت سرویس IT ( که به آن استراتژی سرویس ( Service Strategy ) یا SS گفته می شود ) .
طراحی سرویس ها برای پشتیبانی از استراتژی ( که به آن طراحی سرویس ( Service Design ) یا SD )
پیاده سازی سرویس ها بر اساس نیازمندی های طراحی شده ( که به آن انتقال سرویس ( Service Transition ) یا ST )
پشتیبانی از سرویس های مدیریتی فعالیت های عملیاتی ( Support the Services Managing the Operational Activities ) یا ( که به آن عملیات سرویس ( Service Operation ) یا SO )
ارتباط بین فازها براساس بهبود مداوم سرویس ها مدیریت می شود ، که مسئولیت سنجش ( Measuring ) و بهبود سرویس ها و به کمال رسیدن فرآیندها را برعهده دارد . پس از مقایسه همه فازها ، یک بازه سرویس ( Service Period ) تمام می شود و یک بازه سرویس دیگر آغاز می شود .
فاز بهبود مداوم سرویس در تمام فازهای چرخه حیات سرویس درگیر می باشد . و مسئولیت سنجش سرویس و فرآیندها ( سنجش سرویس - Service Misurement ) ، و مستندسازی نتایج ( گزارش گیری سرویس - Service Reporting ) براساس بهبود کیفیت سرویس و سنجش فرآیندها ( بهبود سرویس - Service Improvement ) را بر عهده دارد . این بهبودها در بازه بعدی چرخه حیات سرویس پیاده سازی خواهند شد ، مجددا با استراتژی سرویس آغاز می شوند و سپس با طراحی سرویس و انتقال سرویس ، فاز عملیات سرویس البته برای عملیات مدیریتی درطول تمامی بازه های سرویس ادامه می یابد .
با تکامل بازه های سرویس ، ” سود و منافع ” برای هر فاز نگرانی استراتژیک و فازهای تاکتیکی ( استراتژی سرویس ( SS ) ، طراحی سرویس ( SD ) و انتقال سرویس ( ST ) را کاهش خواهد داد . در اینجا فاز عملیات سرویس ( SO ) بهینه سازی شده و نقش اصلی را برعهده می گیرد . در هر چرخه سرویس ( بازه سرویس ) سرویس با نتایج افزایش ارزش ( value ) تجاری و به حداکثر رساندن منافع بهبود خواهد یافت .
برطبق اصول همکاری تجاری ، سرویس های IT وقتی با ارزش می شوند ، که در قدم اول مرحله انتقال سرویس ( ST ) آغاز شود .
برطبق اصول سود و منافع ، در سرویس های IT مهمترین سرمایه گذاری ، نیازمند پیاده سازی بزرگ پروژه هاست ( ST ). هنگامی که انتقال ( Transition ) به اتمام می رسد و عملیات ( Operation ) آغاز می شود ، سرویس شروع می کند به پشتیبانی از فرآیندهای تجاری ، و درآمدهای جدید ، هزینه ها را تعدیل می کند . پس از چند بازه بهینه سازی سرویس ، ” سود و زیان ” شروع می کند به سودرسانی و به ” شکستن توانهای زوج ( break even point ) ” میل می کند .
پس از چند بازه ( بسته به پیچیدگی سرویس و انعطاف پذیری تجارت ) همکاری تجاری و سود و منافع ثابت می شوند ، که این بدان معناست که موسسات IT ، به سطح صحیحی از سنجش در مدیریت فرآیندها ، و سرویس به سطح صحیحی از کارایی در ملاقات نیازمندی های سطح سرویس ( performance in meeting the service level requirements ) رسیده اند .
منبع : ‌http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library#Long_Description

کلیاتی از کتابخانه ITIL v2

کتابخانه زیربنایی فن آوری اطلاعات ( IT Infrastructure Library - ITIL ) از یک مجموعه کتاب تشکیل شده است که هر یک ، یک تجربه ( Practice ) در مدیریت سرویس فن آوری اطلاعات ( IT Service Management - ITSM ) را پوشش می دهد ، تعداد جلدهای کتاب های کتابخانه ITIL به سرعت از نسخه یک زیاد شده و به 30 جلد رسیده است . به منظور بیشتر در دسترس قرار دادن ITIL به آنهایی که علاقمند به مرور آن هستند ، یکی از اهداف نسخه دوم ITIL یکپارچه سازی و یکی کردن نشرها در دسته های منطقی است که نسبت به مفاهیم مدیریت IT ، برنامه و سرویس در گروه های جداگانه ای قرار گرفته اند .
در حالی که دسته مدیریت سرویس ( Service Management ) که حاوی Service Support , Service Delivery می باشد بیشتر از سایر دسته ها منتشر شده ، فهمیده شده و مورد استفاده قرار گرفته است ، ITIL یک دسته بزرگتر ( ‌وسیعتر ) از تجربیات را فراهم کرده که دست نخورده باقی مانده است . طرفداران بر این باورند که استفاده از یک کتابخانه وسیعتر ( broad ) یک دسته بزرگ از راهنمایی ها را به یک پیاده سازی تکنیکی ( Technical Implementation ) ، راهنمای عملیات و نیازمندی ها ( Operations Guidlines and Requirements ) با استفاده از مدیریت استراتژیک ( strategic management ) ، مدیریت عملیات ( operations management ) و مدیریت مالی تجارت مدرن ( financial management of a modern business ) پیوند می دهد .
کتابها و نظام های ITIL v2 عبارتند از :
دسته مدیریت سرویس ( Service Management ) :
تحویل سرویس ( Service Delivery )
پشتیبانی سرویس ( Service Support )
دیگر راهنماهای عملیات
مدیریت زیربنای فن آوری اطلاعات و ارتباطات ( ICT Infrastructure Management )
مدیریت امنیت ( Security Management )
دید تجاری ( The Business Perspective )
مدیریت برنامه ( Application Management )
مدیریت دارایی های برنامه ( Software Asset Management )
برای کمک به پیاده سازی تجربیات ITIL یک کتاب کمکی منتشر شد که راهنمایی هایی را در پیاده سازی ( بیشتر در ارتباط با مدیریت سرویس - Service Management - ) فراهم می کرد .
برنامه ریزی برای پیاده سازی مدیریت سرویس ( Planning to Implement Service Management )
ودر این اواخر ضمیمه هایی برای راهنمایی شرکت های کوچک IT اضافه شده است ، که در هشت کتاب منتشر شده اصلی موجود نیست :
پیاده سازی ITIL در مقیاس کوچک ( ITIL Small-Scale Implementation )
ITIL در یک فرآیند-مدل ( Process-Model ) بر اساس دید کنترلی و مدیریت عملیات ایجاد شده ، و اغلب به W. Edwards Deming نسبت داده می شود . توصیه های ITIL دردهه 1980 بوسیله سازمان دولتی CCTA انگلستان ، برای پاسخ دهی به وابستگی رو به رشد در IT و شناسایی استانداردهای بدون تجربه ، ‌آژانس های دولتی و قراردادهای محرمانه ای ( Private Sector Contract ) که بطور مستقل تجارب مدیریت ITمی ساختند و تلاش دوباره در پروژه های Information and Communications Technology (ICT) که منجر به بروز خطاهای عمومی و افزایش هزینه ها می شد ، توسعه پیدا کرد . در آوریل ( اردیبهشت ) 2001 ، CCTA با Office of Government Commerce - OGC, که یک دفتر ( اداره ) در UK Treasury بود ادغام شد .
یکی از مهمترین مزایای این امر در رابطه با ITIL در حوزه IT Community تهیه کردن فرهنگ لغات بود . که دربرگیرنده موارد ( terms ) تعریف شده دقیق و با مقبولیت عمومی گسترده بود . یک واژه نامه جدید و اضافه هم ، مانند یک کلید قابل حمل برای ITIL v3 ( که با نام پروژه بازنگری مجدد ITIL یا ITIL Refresh Project شناخته می شود ) توسعه پیدا کرد .
منبع :‌ http://en.wikipedia.org/wiki/ITIL

( موارد مشابه ) جایگزین های ITIL

ITSM - IT Service Management در جایگاه مفهوم مرتبط است اما با ITIL در نسخه دو که دربرگیرنده یک زیربخش با نام IT Service Management می باشد ، برابر ( یکی ) نیست . ( پنج جلد از نسخه سوم زیربخش مربوطه دارای محدوده مشخصی نیست ) . ترکیب جلدهای پشتیبانی سرویس ( Service Support ) و تحویل سرویس ( Service Delivery ) با محدوده استاندارد ISO / IEC 20000 ( قبلی BS 15000 ) برابر هستند .
خارج از ITIL دیدگاه های دیگر IT Service Management و زیربناها ( Frameworks ) وجود دارند که شامل ; کتابخانه Enterprise Computing Institute's است که دربرگیرنده مسایل ( Issue ) عمومی ( General ) در سطح کلان مدیریت IT است .
The British Educational Communications and Technology Agency - BECTA زیربنای پشتیبانی تکنیکی فن آوری اطلاعات و ارتباطات ، ( FITS - Framework for ICT Technical Support ) را که بر اساس ITIL است را توسعه داد ، اما فقط برای مدارس اصلی و ثانویه انگلیس ( که معمولا دارای واحدهای IT کوچک بودند ) مورد استفاده قرار گرفت . بطور مشابه The Visible OPS Handbook: Implementing ITIL in 4 Practical and Auditable Steps که بر اساس ITIL بود ، بطور خاص بر روی بزرگترین المان های bang for the buck متمرکز شد .
سازمان هایی که لازم دارند تا بدانند که فرایند ITIL چگونه به رنج بیشتر فرآیندهای IT لینک ( متصل ) می شود و یا آنها که نیاز سطح وظیفه ( Task Level ) برای راهنمایی پیاده سازی مدیریت سرویس دارند می توانند ازIBM Tivoli Unified Process - ITUP استفاده نمایند ،ITUP هم‌ مانند MOF ، هم بر اسا ITIL طراحی شده اما یک فرآیند یکپارچگی مدل ( Integrated Process Model ) کامل را معرفی می کند .
سازمان های کوچک که نمی توانند Material ها و یک برنامه کامل ITIL را بکار بگیرند می توانند از Microsoft Operations Framework که بر اساس ITIL و با محدودیت های بیشتری تعریف شده استفاده نمایند .
The enhanced Telecom Operations Map eTOM که بوسیله TeleManagement Forum منتشر شد یک زیربنا ( Framework ) را پیشنهاد می کند که هدف آن فراهم کنندگان سرویس های مخابراتی ( telecomminucations service providers ) است . tmForum و itSMF با به هم پیوستن یک Application Note to eTOM ( GB921 V, version 6.1 را در سال 2005 توسعه دادند که نسخه بعدی برای تابستان 2008 آماده خواهد شد ) آن نشان می دهد که چگونه دو زیر بنا ( Framework ) می توانند به یکدیگر map شوند . همچنین نشان می دهد که چگونه المان های فرآیندهای eTom و گردش های ( Flows ) آن می توانند به منظور پشتیبانی فرآیندهای تعریف شده در ITIL استفاده شوند .
منبع : http://en.wikipedia.org/wiki/ITIL

تاریخچه ITIL

بن مایه

تعداد زیادی از مفاهیم توسط UK Government's Central Computer and Telecommunications Agency (CCTA) برای توسعه و ایجاد ITIL بوجود نیامد ، بلکه توسط IBM تعریف شد .
در اوایل دهه 80 میلادی IBM مفهوم سیستم های اصلی ( Original System concept ) در چهار جلد با عنوان یک سیستم مدیریت برای سیستمهای اطلاعاتی ( A Management System for Information Systems ) منتشر کرد . اینها به عنوان نشریات زرد ( Yellow Book ) پذیرفته شدند و که پایه های ITIL را بنا نهادند .
نویسنده اصلی کتاب های زرد IBM شخصی با نام Edward A. Van Schaik بود که آنها را در کتاب یک سیستم مدیریتی برای اطلاعات تجاری ( A Management System for the Information Business ) جمع آوری نمود . که در سال 2006 توسط انتشارات رد سوان ( Red Swan Publishing ) بروز رسانی شد . در کاری که ون شایک ( Van Schaik ) در سال 1985 انجام داد ، او از کاری که Richard L. Nolan در سال 1974 در کتاب مدیریت قابلیت منابع داده ای ( Managing the Data Resource Function ) منتشر کرده بود و درواقع می توان از آن به عنوان اولین منابع مدیریت IT در سطح کلان یاد کرد ، استفاده کرده بود .

توسعه

آنچه که امروز نسخه یک ITIL نامیده می شود ، با توجهات CCTA - Central Computer and Telecommunications Agency توسعه پیدا کرد و با عنوان متودولوژی مدیریت فن آوری اطلاعات دولتی ( Government Information Technology Infrastructure Management Methodology ) و یا GITMM نام گذاری گردید . و طی سالها به 31 جلد تحت رهبری Peter Skinner و John Stewart در CCTA افزایش و توسعه پیدا کرد .
در اواخر دهه 80 میلادی CCTA از سوی شرکت های IT که می خواستند از سرویس مشاوره دولت استفاده کنند و نیز از سوی سازمان های دولتی که از چشم افتاده بودند مورد حملات شدیدی قرار گرفت . و سرانجام CCTA تسلیم شد و مفهوم central driving IT authority for the UK Government از بین رفت . این به معنای آداپته کردن راهنماهای CCTA مانند ITIL بود که به تاخیر افتاد .
در برخی موارد راهنماها به کلی از بین رفتند . CCTA IT Security و Privacy group وارد شدن CCTA IT Security Library را به GITMM فراهم کردند ، اما Security Service وقتی که CCTA از بازی خارج شد امور این بخش را به عهده گرفت و در ادامه جنگی که بر سر مسئولیت های امنیتی داشتند ، ادامه کار را متوقف کرد.
همچنان که در دهه 80 میلادی ITIL توسعه پیدا می کرد ، به دلایلی که در بالا بدان ها اشاره شد ، تا میانه دهه 90 میلادی آداپته نشد . این زمان زیاد آداپته شدن و آگاهی های بدست آمده ، منجر به ایجاد تعدادی استاندارد شد ، که شامل ISO/IEC 20000 ، که در برگیرنده و معرف استاندارد بین المللی IT Service Management هست نیز می باشد .ITIL اغلب در کنار دیگر تجربیات موفق ( Best Practice ) مانند Information Service Procurement Library - ISPL و Application Services Library - ASL و Dynamic Systems Development Method - DSDM و Capability Maturity Model - CMM / CMMI قرار می گیرد . و اغلب بوسیله Control Objectives for Informayion and Related Technology - COBIT با موسسات IT دولتی (‌وابسته به دولت ) پیوند داده می شود .در ماه دسامبر ( آذر ) 2005 میلادی OGC یک بازنگری در ITIL انجام داد که به ITIL v3 یا نسخه سوم ITIL مشهور شده است و در ماه May ( خرداد ) 2007 در دسترس عموم قرار گرفت . نسخه سوم ITIL پنج نقطه مرکزی دارد :
Service Strategy -- استراتژی سرویس
Service Design -- طراحی سرویس
Service Transition -- انتقال سرویس
Service Operation -- عملیات سرویس
Continual Service Improvement -- بهبود مداوم سرویس
این پنج اصل بسیاری از نشرهای نسخه دو ، ITIL v2 - را بروز رسانی ( update ) کرد و محدوده و حوزه فعالیت های ITIL را در مدیریت سرویس ها ( Service Management ) توسعه داد

।منبع :‌http://en।wikipedia.org/wiki/ITIL

Service Desk - ITSM

Service Desk مهمترین قابلیت و کاربرد IT Service Management ( ITSM ) بر اساس تعاریف Information Technology Infrastructure Library ( ITIL ) می باشد । و برای ایجاد یک نقطه اشتراک ( Single Point of Contact - SPOC ) بین کاربران و راضی نگه داشتن مشتری ها و راهم کنندگان خدمات IT بوجود آمد . تعداد بیشماری از سازمانها ، یک نقطه ارتباطی مشترک را برای پاسخگویی به مشتری ها ، کاربران و افراد مرتبط ( کاربر یا User به کسی گفته می شود که از سرویس استفاده می نماید و مشتری یا Customer به کسی اطلاق می شود که در ازای دریافت سرویس مبلغی را پرداخت کرده است ) ایجاد کرده اند . قابلیت های Service Desk به چند بخش تقسیم می شود . که شامل :

Call Center - نقطه تماس مرکزی

Contact Center - نقطه ارتباط مرکزی

Help Desk - بخش پشتیبانی

Service Desk - بخش ارائه سرویس و خدمات

از دیدگاه ITIL تنها نقطه ارتباطی مابین فراهم کننده سرویس ( ارائه کننده خدمت ) و مشتری یا کاربر ( سرویس گیرنده ) ServiceDesk است । همچنین ServiceDesk یک نقطه مرکزی برای گزارش Incident ها ( رخدادها ) و اشخاصی است که درخواست دریافت سرویس ( Service request ) دارند . Service Desk رخدادها ( Incident ) و درخواست های سرویس ( Service Request ) را هندل کرده و با استفاده از یک رابط کاربری ، سایر فعالیت های ITSM را ( که در زیر لیست شده ) پشتیبانی می کند :
Incident Management - مدیریت رخدادها
Problem Management - مدیریت مشکلات
Configuration Management - مدیریت تنظیمات ( پیکربندی ها )
Change Management - مدیریت تغییرات
Release Management - مدیریت ارائه شده ها ( نسخه نهایی محصول که به بازار ارائه می شود )
Service Level Management - مدیریت سطح سرویس
Availability Management - مدیریت موجودی ها ( داشته ها - آن چیزهایی که در دسترس است )
Capacity Management - مدیریت ظرفیت
Financial Management - مدیریت مالی
IT Service Continuty Management - مدیریت سرویس هایIT دنباله دار
Security Management - مدیریت امنیت
Service Desk به سرعت زیادی کاربران را از رخدادهای سرویس - فعالیت های انجام شده بر روی آن - تغییرات مطلع می کند . Service Desk در خط مستقیم تمامی اتفاقات مهم قرارداد سطح سرویس ( Service Level Agreement - SLA ) و آنجایی که باید تغییرات ، طرح ها و دردسترس نبودن سرویس ها به سرعت انجام شود ، قرار دارد .
Service Desk با نقطه تماس مرکزی ( Call Center ) ، نقطه ارتباط مرکزی ( Contact Center ) و یا Help Desk متفاوت استو این تفاوت دردید مرکز گرایانه و وسعت بیشتر آن است که تلاش می کند که نیازهای ICT کاربران را تنها و تنها فقط از یک نقطه مرکزی اداره کند . Service Desk تلاش می کند تا یکپارچگی فرایند تجارت ( Business Process ) را در قالب و چارچوب مدیریت سرویس ها ( Service Management Infrastructure ) تسهیل نماید . با توجه به مانیتور کردن فعالانه و مالکیت رخدادها و درخواست کاربران و فراهم کردن یک کانال ارتباطی برای دیگر نظام های مدیریت های سرویس ( Service Management Deciplines ) با جامعه کاربران یک Service Desk یک واسط برای فعالیت های دیگری مانند درخواست تغییرات کاربران ، برنامه های دیگر ( third Party ) و درخواست های مجوز نرم افزار ( Software Licensing Request ) فراهم می کند .
اهداف ServiceDesk عبارتند از :
فراهم کردن یک نقطه ارتباطی مشترکبرای تمامی مشتری ها .
تسهیل بازیابی سرویس های عملیاتی معمولی با حداقل میزان اهمیت ( impact ) تجاری برای مشتری هایی که قراردادهای سطح سرویس - SLA - را پذیرفته اند و با توجه به میزان اهمیت تجاری .
کاربردهای معمول Service Desk عبارتند از :
دریافت تماس ها ، اولین گروه پاسخگوی مشتری ها
ضبط و پیگیری رخدادها و شکایات
مطلع کردن مشتری ها از وضعیت درخواست و مرحله پردازش
اظهار نظر کردن ابتدایی برای درخواست ، سعی در حل آن و یا ارجاع آن به شخصی که می تواند مشکل را حل کند
مانیتور کردن و پاسخگویی و حل مشکل در بازه زمانی مشخص شده در قرارداد سطح سرویس - SLA .
شناسایی مشکلات
حل ( بستن ) مشکلات و گرفتن تاییدیه از مشتری
هماهنگ کردن پشتیبانی سطح دوم و سوم
چنانچه مشاهده می شود درخواست های سرویس که با Service Desk پیگیری می شوند یک فرآیندهستند ، درحالی که ITIL پیشنهاد می کند ( می گوید ) که Service desk یک کاربرد ( Function ) است و نه یک فرایند ( Process ) .
منبع : http://en.wikipedia.org/wiki/Service_Desk_(ITSM)

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 ها با برنامه هاي راه دور مي توانند برخي از مشكلات را رفع كنند .