کتابخانه زیربنایی فناوری اطلاعات

یک آویز گواهی بنیاد آی‌تی‌ای‌ال (کتابخانه زیربنایی فناوری اطلاعات).

در اوایل دهه ۸۰ میلادی آی‌بی‌ام مفهوم سیستم‌های اصلی^∗ در چهار جلد با عنوان یک سیستم مدیریت برای سامانه‌های اطلاعاتی^∗ منتشر کرد. این‌ها به عنوان نشریات زرد^∗ پذیرفته شدند و که پایه‌های کتابخانه زیربنایی فناوری اطلاعات را بنا نهادند.

نویسنده اصلی کتاب‌های زرد آی‌بی‌ام شخصی با نام ادوارد فان اسخایک بود که آنها را در کتاب یک سیستم مدیریتی برای اطلاعات تجاری^∗ جمع‌آوری نمود. که در سال ۲۰۰۶ توسط انتشارات رد سوان^∗ بروز رسانی شد. در کاری که فان اسخایک در سال ۱۹۸۵ انجام داد، او از کاری که ريچارد نولان (Richard L. Nolan) در سال ۱۹۷۴ در کتاب مدیریت قابلیت منابع داده‌ای ^∗ منتشر کرده بود و در واقع می‌توان از آن به عنوان اولین منابع مدیریت فناوری اطلاعات در سطح کلان یاد کرد، استفاده کرده بود.

شمار زیادی از مفاهی مبرای توسعه و ایجاد کتابخانه زیربنایی فناوری اطلاعات (ITIL) توسطUK Government’s Central Computer and Telecommunications Agency (CCTA) بوجود نیامد، بلکه توسط IBM تعریف شد.

توسعه

آنچه که امروز نسخه یک کتابخانه زیربنایی فناوری اطلاعات (آیدل) نامیده می‌شود، با توجهات CCTA - Central Computer and Telecommunications Agency توسعه پیدا کرد و با عنوان روش‌شناسی مدیریت فناوری اطلاعات دولتی (Government Information Technology Infrastructure Management Methodology) و یا GITMM نام گذاری گردید. و طی سالها به ۳۱ جلد تحت رهبری Peter Skinner و John Stewart در CCTA افزایش و توسعه پیدا کرد.

در اواخر دهه ۸۰ میلادی 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 از بازی خارج شد امور این بخش را به عهده گرفت و در ادامه جنگی که بر سر مسئولیت‌های امنیتی داشتند، ادامه کار را متوقف کرد.

همچنان که در دهه ۸۰ میلادی ITIL توسعه پیدا می‌کرد، به دلایلی که در بالا بدان‌ها اشاره شد، تا میانه دهه ۹۰ میلادی آداپته نشد. این زمان زیاد آداپته شدن و آگاهی‌های بدست آمده، منجر به ایجاد تعدادی استاندارد شد، که شامل ISO/IEC ۲۰۰۰۰، که در برگیرنده و معرف استاندارد بین‌المللی 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 Information and Related Technology – COBIT با موسسات IT دولتی (‌وابسته به دولت) پیوند داده می‌شود. در ماه دسامبر (آذر) ۲۰۰۵ میلادی OGC یک بازنگری در ITIL انجام داد که به ITIL v۳ یا نسخه سوم ITIL مشهور شده‌است و در ماه May (خرداد) ۲۰۰۷ در دسترس عموم قرار گرفت. نسخه سوم ITIL پنج نقطه مرکزی دارد:

1. Service Strategy — استراتژی سرویس
2. Service Design – طراحی سرویس
3. Service Transition – انتقال سرویس
4. Service Operation — عملیات سرویس
5. Continual Service Improvement — بهبود مداوم سرویس

این پنج اصل بسیاری از نشرهای نسخه دو، ITIL v۲ – را بروز رسانی (update) کرد و محدوده و حوزه فعالیت‌های ITIL را در مدیریت سرویس‌ها (Service Management) توسعه داد.

موارد مشابه کتابخانه زیربنایی فناوری اطلاعات

ITSM – IT Service Management در جایگاه مفهوم مرتبط است اما با ITIL در نسخه دو که دربرگیرنده یک زیربخش با نام IT Service Management می‌باشد، برابر نیست. (پنج جلد از نسخه سوم زیربخش مربوطه دارای محدوده مشخصی نیست). ترکیب جلدهای پشتیبانی سرویس (Service Support) و تحویل سرویس (Service Delivery) با محدوده استاندارد ISO / IEC ۲۰۰۰۰ (قبلی BS ۱۵۰۰۰) برابر هستند.

خارج از 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 ۴ 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 (GB۹۲۱ V, version ۶٫۱ را در سال ۲۰۰۵ توسعه دادند که نسخه بعدی برای تابستان ۲۰۰۸ آماده خواهد شد) آن نشان می‌دهد که چگونه دو زیر بنا (Framework) می‌توانند به یکدیگر map شوند. همچنین نشان می‌دهد که چگونه المان‌های فرآیندهای eTom و گردش‌های (Flows ) آن می‌توانند به منظور پشتیبانی فرآیندهای تعریف شده در ITIL استفاده شوند.

Microsoft Opration Framework(MOF): شركت مايكروسافت به منظور ارائه و پشتيباني مطلوب از خدمات و محصولات خود به مشتريان، يك چارچوب عملياتي مبتني بر ITIL توسعه داده است. چارچوب عملياتي مايكروسافت(MOF ) شامل مجموعه‌اي از بهترين شيوه‌ها، فرايندها و رهنمودهای كاربردي به منظور کسب اطمينان از راه‌حل‌ها و خدمات IT است. اين چارچوب با ارايه راهنمايي‌هایی به صورت سوال و جواب، به كاربران اجازه مي‌دهد تا علاوه بر تعيين نيازهاي سازمان، فعاليت‌هايي که واحد IT براي افزايش بهره‌وري و اثربخشي نياز دارد،‌ مشخص نمايند. راهنمايي‌هاي موجود در MOF تمام فعاليت‌ها و فرآيندهای درگير در يک سرويس IT، شامل طرح اوليه، توسعه، به‌کارگيری، نگهداری و در نهايت از رده خارج شدن سرويس،‌ را در برمي‌گيرد.

کلیاتی از کتابخانه زیربنایی فناوری اطلاعات نسخه ۲

کتابخانه زیربنایی فن آوری اطلاعات (IT Infrastructure Library – ITIL) از یک مجموعه کتاب تشکیل شده‌است که هر یک، یک تجربه (Practice) در مدیریت سرویس فن آوری اطلاعات (IT Service Management – ITSM) را پوشش می‌دهد، تعداد جلدهای کتاب‌های کتابخانه ITIL به سرعت از نسخه یک زیاد شده و به ۳۰ جلد رسیده‌است. به منظور بیشتر در دسترس قرار دادن 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 v۲ عبارتند از :

دسته مدیریت سرویس (Service Management) :

1. تحویل سرویس (Service Delivery )
2. پشتیبانی سرویس ( Service Support )

دیگر راهنماهای عملیات

1. مدیریت زیربنای فن آوری اطلاعات و ارتباطات ( ICT Infrastructure Management )
2. مدیریت امنیت ( Security Management )
3. دید تجاری (The Business Perspective )
4. مدیریت برنامه (Application Management )
5. مدیریت دارایی‌های برنامه ( Software Asset Management )

برای کمک به پیاده سازی تجربیات ITIL یک کتاب کمکی منتشر شد که راهنمایی‌هایی را در پیاده سازی (بیشتر در ارتباط با مدیریت سرویس – Service Management –) فراهم می‌کرد.

1. برنامه ریزی برای پیاده سازی مدیریت سرویس (Planning to Implement Service Management)

ودر این اواخر ضمیمه‌هایی برای راهنمایی شرکت‌های کوچک IT اضافه شده‌است، که در هشت کتاب منتشر شده اصلی موجود نیست :

1. پیاده سازی ITIL در مقیاس کوچک ( ITIL Small-Scale Implementation )

ITIL در یک فرآیند-مدل (Process-Model ) بر اساس دید کنترلی و مدیریت عملیات ایجاد شده، و اغلب به W. Edwards Deming نسبت داده می‌شود. توصیه‌های ITIL دردهه ۱۹۸۰ بوسیله سازمان دولتی CCTA انگلستان، برای پاسخ دهی به وابستگی رو به رشد در IT و شناسایی استانداردهای بدون تجربه، آژانس‌های دولتی و قراردادهای محرمانه‌ای (Private Sector Contract ) که بطور مستقل تجارب مدیریت ITمی ساختند و تلاش دوباره در پروژه‌های Information and Communications Technology (ICT) که منجر به بروز خطاهای عمومی و افزایش هزینه‌ها می‌شد، توسعه پیدا کرد. در آوریل (اردیبهشت) ۲۰۰۱، CCTA با Office of Government Commerce – OGC، که یک دفتر (اداره) در UK Treasury بود ادغام شد.

یکی از مهمترین مزایای این امر در رابطه با ITIL در حوزه IT Community تهیه کردن فرهنگ لغات بود. که دربرگیرنده موارد (terms) تعریف شده دقیق و با مقبولیت عمومی گسترده بود. یک واژه نامه جدید و اضافه هم، مانند یک کلید قابل حمل برای ITIL v۳ (که با نام پروژه بازنگری مجدد ITIL یا ITIL Refresh Project شناخته می‌شود ) توسعه پیدا کرد.

کلیاتی از کتابخانه زیربنایی فناوری اطلاعات نسخه ۳

ITIL v۳ در ماه may (خرداد) ۲۰۰۷ منتشر شد و شامل پنج جلد کلیدی (key volumes ) است :

• استراتژی سرویس (Service Strategy)
• طراحی سرویس (Service Design)
• انتقال سرویس (Service Transition)
• عملیات سرویس (Service Operation)
• بهبود مداوم سرویس (Continual Service Improvement)

راهبرد سرویس

استراتژی سرویس در مرکز (هسته) چرخه زندگی ITIL v۳٫۱ قرار گرفته اما نمی‌تواند به تنهایی و بدون سایر بخش‌های ساختار 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) می‌باشد.

طراحی سرویس

طراحی سرویس 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 ) می‌باشد.

انتقال سرویس

انتقال سرویس به تحویل سرویس‌هایی مربوط می‌شود که نیاز تجاری فعال / عملیاتی (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)

را شامل می‌شود.

عملیات سرویس

تجربه موفق در گروی نائل شدن به تحویل سطوح مورد پذیرش (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) می‌شوند.

بهبود مداوم سرویس

شرح کوتاه

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

بهبود مداوم سرویس باید مانند سایر تجربیات موفق عمل شود. آنها نیازمند یک برنامه ریزی بالا به پیش رو (upfront )، آموزش و اطلاع رسانی، زمان بندی مداوم، ایجاد نقش‌ها، نسبت دادن به خود، و فعالیت‌ها براساس میزان موفقیت شناسایی می‌شوند. بهبود مداوم سرویس باید مانند فرآیندها با فعالیت‌های تعریف شده، ورودی‌ها، خروجی‌ها، نقش‌ها و گزارش‌ها برنامه ریزی و زمان بندی شود. FHD

شرح کامل

مادامی که موسسه در حال شناسایی سرویس‌هایش است (اینکه چه سرویس‌هایی دارد)، همچنین فرآیند توسعه و پیاده سازی مدیریت سرویس فن آوری اطلاعات (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 ) رسیده‌اند.

جزئیات کتابخانه زیربنایی فناوری اطلاعات نسخه ۲

پشتیبانی سرویس

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

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

• درخواست تغییرات (Asking for Changes)
• لزوم ارتباطات، بروز رسانی‌ها (Needing Comminucation , Updates)
• درگیر شدن، پرس و جو (Having Difficulties , Queries)
• انتقال واقعی فرآیند (Real process delivery)

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

مدیریت درخواست سرویس

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

• تنها نقطه ارتباط (SPOC – Single Point of Contact ) و نه لزوما اولین نقطه ارتباط (FPOC – First Point of Contact ).
• تنها یک نقطه ارتباطی ورود و خروج وجود دارد
• سهولت استفاده برای مشتری‌ها
• یکپارچگی داده‌ها
• کانال ارتباطی سریع، مفید، موثر و پرکاربرد است

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

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

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

کارکرد Servicedesk تحت عناوین مختلفی شناخته می‌شود:

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

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

• Local Service Desk (داخلی) : برای برطرف کردن نیازهای تجاری محلی – فقط تا زمانی یک ابزار تمرینی است که در چندین محل درخواست سرویس داشته باشند.
• Central Service Desk (مرکزی) : برای برطرف کرذن نیاز موسساتی که دارای چندین محل هستند – هزینه‌های عملیاتی را پایین آورده و به کارگیری منابع موجود را بهبود می‌بخشد.
• Virtual Service Desk (مجازی) : برای برطرف کردن نیاز سازمان‌هایی که در چند کشور قرار گرفته‌اند – می‌تواند با بهره گیری از مزایای بهبود شبکه و مخابرات، از هر نقطه‌ای در جهان مورد دسترسی قرار بگیرد. و منجر به کاهش هزینه‌های عملیاتی و بهبود بکارگیری منابع موجود شود.

مدیریت رخداد

هدف مدیریت رخداد، بازگرداندن عملیات سرویس دهی به شکل معمول و نرمال، در کمترین زمان ممکن و به حداقل رساندن اثرگذاری مضرات (ناسازگاری‌ها)‌در عملیات تجاری است. بنابراین تضمین می‌شود که بهترین سطوح کیفیت سرویس و در دسترس بودنِ (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

پاورقی

1. ^  Original System concept
2. ^ A Management System for Information Systems
3. ^ Yellow Book
4. ^ A Management System for the Information Business
5. ^ Red Swan Publishing
6. ^ Managing the Data Resource Function
7. ^ 
8. ^ 
9. ^ 
10. ^ 
11. ^ 
12. ^ 
13. ^ 
14. ^ 
15. ^ 
16. ^ 
17. ^ 
18. ^ 
19. ^ 
20. ^ 
21. ^ 
22. ^ 
23. ^ 
24. ^ 
25. ^ 
26. ^ 
27. ^ 
28. ^ 
29. ^ 
30. ^ 
31. ^ 
32. ^ 
33. ^ 
34. ^ 
35. ^ 
36. ^ 
37. ^ 
38. ^ 
39. ^ 
40. ^ 
41. ^ 
42. ^ 
43. ^ 
44. ^