کتابخانه زیربنایی فناوری اطلاعات
در اوایل دهه ۸۰ میلادی آی‌بی‌ام مفهوم سیستم‌های اصلی در چهار جلد با عنوان یک سیستم مدیریت برای سامانه‌های اطلاعاتی منتشر کرد. این‌ها به عنوان کتاب زرد پذیرفته شدند و پایه‌های کتابخانه زیربنایی فناوری اطلاعات را بنا نهادند.
نویسنده اصلی کتاب‌های زرد آی‌بی‌ام شخصی با نام ادوارد فان اسخایک بود که آنها را در کتاب یک سیستم مدیریتی برای اطلاعات تجاری جمع‌آوری نمود؛ که در سال ۲۰۰۶ توسط انتشارات رد سوان بروز رسانی شد. در کاری که فان اسخایک در سال ۱۹۸۵ انجام داد، او از کاری که ریچارد نولان (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 پنج نقطه مرکزی دارد:
- Service Strategy — استراتژی سرویس
- Service Design – طراحی سرویس
- Service Transition – انتقال سرویس
- Service Operation — عملیات سرویس
- 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 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 ۶٫۱ را در سال ۲۰۰۵ توسعه دادند که نسخه بعدی برای تابستان ۲۰۰۸ آماده خواهد شد) آن نشان می‌دهد که چگونه دو زیر بنا (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):
- تحویل سرویس (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 دردهه ۱۹۸۰ به وسیلهٔ سازمان دولتی 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