مدل ارزیابی بلوغ ITIL4

متأسفانه تا پیش از این چارچوب ITIL فاقد متدی برای ارزیابی بود و نمی‌شد تمرینات و انطباق آن را توسط خودش ارزیابی کرد. تا چندی قبل فقط با کمک مدل انطباق  TIPA و ISO20000 معمولاً این کار انجام می‌شد که یک نقص مهم برای ITIL به‌حساب می‌آمد. ولی بنیاد Axelos اخیراً اولین مدل بلوغ ITIL را بر اساس مفاهیم مورداستفاده در چارچوب ITIL4 منتشر کرده و درست از زمان انتشار مدل و ارزیابی بلوغ ITIL همراه با آن، سؤالات زیادی از سوی مدیران فناوری اطلاعات مطرح‌شده که این متد ارزیابی چگونه کار می‌کند؟

در این مطلب کامل کلیه موارد مربوط به ارزیابی‌هایی که توسط مدل بلوغ ITIL موردتوجه قرارگرفته را شرح داده‌ام:

• ارزیابی مدل بلوغ  ITIL
• انواع متدها ارزیابی‌ بلوغ
• مهاجرت از ITIL v3 به  ITIL4
• شیوه‌ها‌ی ارزیابی
• آنچه در طول ارزیابی انتظار می‌رود؟
• گرفتن گواهی بلوغ

مسائل مربوط به کسب‌وکار توسط مدل بلوغ ITIL که Axelos عرضه کرده اولین و تنهاترین ابزار ارزیابی اختصاصی مدیریت خدمات فناوری اطلاعات یا (ITSM) در جهان است که بر اساس مفاهیم توسعه‌یافته به‌عنوان بخشی از چارچوب ITIL4 توسعه‌یافته است.

این مدل به یک سازمان فناوری اطلاعات اجازه می‌دهد تا وضعیت فعلی ITSM خود را بدون تعصب داخلی یا خارجی ارزیابی کند. یافته‌ها معمولاً برای شناسایی و اولویت‌بندی نقاط ضعف ITSM  استفاده می‌شود، بنابراین رهبری می‌داند که منابع و تلاش‌های بهبود را در کجا متمرکز کند و / یا می‌تواند پیشرفت‌های مرتبط با ابتکار بهبود را که قبلاً در حال انجام است، ردیابی کند.

اگرچه تمرکز مدل بلوغ ITIL بر فناوری اطلاعات سازمان و ITSM است، اما می‌تواند فراتر از صرفاً ارزیابی فرایندها یا تمرینات انفرادی باشد. درواقع، یک سازمان می‌تواند از این مدل برای ارزیابی اکوسیستم فناوری اطلاعات بزرگ‌تر ازجمله عناصری مانند فرهنگ، حاکمیت، بهبود و نوآوری و نحوه تعامل فرایندها با یکدیگر استفاده کند. به‌عبارت‌دیگر، مدل بلوغ ITIL می‌تواند برای ارزیابی کل سیستم ارزش خدمات (SVS) استفاده شود. ازاین‌رو یک نتیجه‌ی واحد و مشخص برای همه مناسب نیست بخاطر همین مدل بلوغ ITIL دارای سه نوع ارزیابی برای پاسخگویی به نیازهای مختلف است.

ارزیابی توسط یک مشاور معتبر و باتجربه و یا یک شریک مشاوره Axelos Certified  باید انجام ‌شود تا اطمینان حاصل گردد که دیدگاه مستقل توسط یک متخصص ITSM باتجربه ارائه‌شده است یا خیر؟

مدل بلوغ ITIL جایگاهی در حمایت از برنامه‌های بهبود فناوری اطلاعات و تحولات دیجیتال دارد.

رابطه “سنتی” بین استراتژی کسب‌وکار، دیجیتال و فناوری اطلاعات

قبل از اینکه کسی از اصطلاح “تحول دیجیتال” استفاده کند، اوج موفقیت بسیاری از تیم‌های فناوری اطلاعات تبدیل‌شدن به یک شریک قابل‌اعتماد بود که از کسب‌وکار حمایت می‌کرد. این معمولاً به معنای اطمینان از فرایندهای فناوری اطلاعات مؤثر، کارآمد و پاسخگویی به نیازهای مشتریان داخلی کسب‌وکار است. همچنین شامل هماهنگی نزدیک استراتژی فناوری اطلاعات با استراتژی سازمانی / کسب‌وکار بزرگ‌تر بود، زیرا به‌طور سنتی، استراتژی کسب‌وکار، استراتژی فناوری اطلاعات و استراتژی دیجیتال متفاوت بود. برای سازمان‌هایی که هنوز تحت تحول دیجیتال قرار نگرفته‌اند، ارزیابی بلوغ ITIL می‌تواند برای اطمینان از اینکه حاکمیت فناوری اطلاعات، شیوه‌ها و گردشکار از سازمان بزرگ‌تر حمایت می‌کند، مورداستفاده قرار گیرد.

استراتژی در یک سازمان دیجیتال

این روزها، همه در مورد تحول دیجیتال صحبت می‌کنند، اصطلاحی که می‌تواند برای افراد مختلف متفاوت باشد.

 انتشارات ITIL4 Digital and IT Strategy (DITS)  تحول دیجیتال را به‌این‌ترتیب تعریف می‌کند: “استفاده از فناوری دیجیتال برای بهبود قابل‌توجه در تحقق اهداف سازمان که نمی‌توان آن را با استفاده از روش‌های غیر دیجیتال به دست آورد.”

در یک سازمان کاملاً دیجیتالی، استراتژی‌های دیجیتال و فناوری اطلاعات در استراتژی کسب‌وکار / شرکت وجود دارد – هیچ نور روز بین آن‌ها وجود ندارد.

هنگام استفاده از مدل بلوغ ITIL در زمینه تحول دیجیتال، بیش‌ازحد بر روی “دیجیتال” تمرکز نکنید. اجازه دهید استراتژی کسب‌وکار بزرگ‌تر شما، فناوری اطلاعات را برای شناسایی مناطقی که بیشترین ارزش را به ارمغان می‌آورند، هدایت کند و تعیین کند که چگونه بهترین استفاده از ابزار و تکنولوژی را در اختیار شما قرار دهد.

اگرچه ممکن است در ابتدا ناراحت‌کننده به نظر برسد، ولی تغییر رهبری یک فرصت عالی برای شما است: هنگامی‌که رهبری تغییر می‌کند، همه‌چیز می‌تواند تغییر کند. اکنون بهترین زمان برای در نظر گرفتن آنچه یک تحول دیجیتال می‌تواند برای سازمان شما باشد و چگونه ارزیابی بلوغ ITIL می‌تواند اطمینان حاصل کند که IT آماده پشتیبانی یا هدایت تغییراتی است که موفقیت را امکان‌پذیر می‌کند. این بار را به‌عنوان فرصتی برای تجدیدنظر در استراتژی دیجیتال و فناوری اطلاعات خود در نظر بگیرید و آنچه را که می‌خواهید بر اساس استراتژی کسب‌وکار / کسب‌وکار بزرگ‌تر خود به دست آورید، اولویت‌بندی کنید.

ادامه مطلب در صفحه بعد…

نوشته مدل ارزیابی بلوغ ITIL4 اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

مدیریت زمان در مدیریت خدمات

بیت‌کوین، یک ارز جدید یا رمزارز دیجیتالی، معتبر و جهانی است که اخیراً هم بسیار ارزشمند شده. ارزی که برای به‌دست‌آوردنش باید هزاران وات برق مصرف کرد. اما می‌خواهم یک رمزارز جدید را معرفی کنم. یک پول معتبر، که با نوسانات طلا و دلار و یا تشویق‌های مدیرعامل تسلا (ایلان ماسک) ارزش‌اش بالا و پایین نمی‌شود. هیچ‌‌کس خود را مالک آن معرفی نکرده و هویت پدیدآورنده‌اش نیز مشخص نیست. برای استخراج‌اش به هیچ دم و دستگاهی نیاز ندارید. از قدیم معتبر بوده و تا ابد هم معتبر خواهد ماند. یک پول بدون پشتوانه است؛ نه وابسته به نه طلاست، نه سیاست و نه به یک ابرقدرت اقتصادی. تمام کشورهای دنیا از نظر حقوقی هم آن‌را به رسمیت می‌شناسند. این رمزارز، معتبرترین، ارزشمندترین و جهانی‌ترین ارزی است که همه‌ی ما به عمرمان دیده‌ایم. اسمش هست بیت‌تایم یا BitTime. یک ارز همیشه رایج، بنام بیت‌زمان. پولی به‌نام زمان!

بیت‌تایم را چطور استخراج کنیم؟ چطور خرج‌ کنیم؟ چطور افزایش‌ بدهیم و راهکارهای تراکنش موفق آن کدامند و در آخر چگونه جلوی سرقت و یا هک آن‌را بگیریم؟

×××

استخراج BitTime

هیچ نیازی به استخراج این ارز معتبر ندارید. همه‌ی آدم‌هایی که به دنیا می‌آیند، یک کیف‌پول پُر از پول، مفت و مجانی به‌همراه‌اشان هست که تا لحظه‌ی مرگ مختارند هر طور دوست دارند آن‌را خرج کنند و یا هدر دهند. زمان، نیازی نیست از جایی استخراج‌اش کنید. فقط باید ببینید آن‌را دارید سپری می‌کنید یا صرف!؟

زمان، یک پول یامفت است! چون مفت است قدرش را نمی‌دانیم! کتاب‌های مدیریت زمان گاهی خسته‌کننده‌اند چون با زبان ساده نمی‌گویند درد این است و درمان این. پرسشی که همیشه مطرح است اینست که اگر وقت طلاست و همه به یک اندازه داریم پس چرا یکی فقیر است یکی ثروتمند؟ برای درک ارزش زمان ببینید آیا دل‌اتان می‌آید یک کیف پُر از اسکناس درشت را آتش بزنید!؟ یا فقط یک سکه‌ی طلا را به جوی فاضلاب بندازید!؟

حتماً که دل‌اتان نمی‌آید چون منم مثل شما هستم. چون قدر این اسکناس‌ها و سکه‌های طلا را خیلی‌خوب می‌دانیم. چون باهاش می‌شود چه‌ها که نخرید! چون برای بدست آوردنش پدر آدم در می‌آید. اما همیشه فراموش می‌کنیم که این‌ها را با فروختن زمان بدست آوردیم! یعنی طلا فروختیم، بیل به‌دست آوردیم! شما به ازای خرج‌کرد زمان، چه چیزی به دست می‌آورید؟ یک کیف پُر از پول؟ یک سکه‌ی طلا و یا سرگرمی و لذایذ سطحی و گذرا؟ این دَم را چطور خرج می‌کنید و اکنون را چگونه فهمیدید؟ اینهمه لاف می‌زنیم که زندگی، یعنی در لحظه بودن آیا فکر می‌کنید تماماً یعنی خوش‌گذرانی و میگساری!؟

در لحظه بودن زندگی یعنی چه!؟

حکیم عمر خیام می‌گوید، این دَم و مارتین هایدگر می‌گوید، اکنون! مگر غیر از اینست که هر دو دارند از زمان سخن می‌گویند و از قدر دانستن آن! اما چرا ما نهصدسال پیش که خیام داشتیم و این‌را می‌گفت نمی‌فهمیدیم!؟

زمان، بهانه‌ای است برای نداشتن! هر چیزی که بدان نرسیم می‌گوییم زمان کافی نداشتم. چطور برای زمان‌ خودمان و زمان دیگران که سپری می‌شود یا صرف می‌شود ارزش قائلیم!؟

آنچه تاکنون از زمان فهمیدیم اینست که زمان، گذر آب در رودخانه است. زمان رهاست، نمی‌توانید صاحب آن شوید، اما می‌توانید ازش استفاده کنید. نمی‌شود آن را نگه داشت اما می‌شود خرجش کرد. وقتی از دست‌اش دادید دیگر نمی‌توانید آن‌را پس بگیرید. زمان، گران‌ترین واحد پولی جهانی و رایج‌ترین پول ماست. اغلب آن را با ارزش‌ترین “منبع درآمد” می‌نامند. یک ارز ارزشمند. اما اگر زمان ارزشمندترین پول ماست، پس چرا با آن چنین برخورد نمی‌کنیم؟ چرا اینقدر فقیریم!؟ مگر همه به یک اندازه زمان در اختیارمان نیست!؟ این فاصله‌ی اجتماعی از کجا می‌آید چرا فلان شخص موفق است و ما نیستیم!؟ مگر غیر از این است که نه زمان، ساخته‌ی دست انسان است و نه انسان، ساخته‌ی زمان، ما آدم‌ها در جبر زمانیم. اما شبیه تمام اجبارهای هستی، زمان نیز موهبتی است که می‌شود از آن مفید استفاده کرد و لذت برد. آب این رودخانه در حال گذرست و بهتر نیست بجای گذاشتن پای‌مان را در این رود به امید خنک شدن، کار دیگری بکنیم؟، آب این رودخانه، هر لحظه‌اش آبی دارد که با لحظه‌ی قبل‌اش فرق می‌کند بهتر نیست به اندازه‌ی اکنون ازش آب برداشت کنیم!؟ و یا آب رودخانه را به سمت مزارع بکشیم تا آبادی و آبادانی ما و دنیای بهتر را رقم بزند!؟

زمان یکسان و همگن است. این یعنی ساعت‌ها، چه مدت و چه مقدار را نشان نمی‌دهند بلکه عدد ثبت شده، فقط اکنون است! زمانی از فرصت‌ها می‌شود استفاده کرد که لحظه‌ی اکنون را درک کرده باشیم! این یعنی همه می‌توانند از این طلای مفت و مجانی که در اختیارشان هست به یک اندازه بهره‌مند شود.

خُب اگر فهمیدیم وقت طلاست و ارزشمندترین ارز جهان چطور با آن معامله کنیم!؟

واحد پول زمان مزایایی دارد این‌که برای داشتن‌ آن نیازی به انجام هیچ کار و زحمتی نیست. تا پایان عمر، رایگان به همه اعطا شده. حالا ما یک خانه‌ی پُر از پول داریم می‌توانیم، خرجش کنیم، آن‌را سرمایه‌گذاری کنیم و یا به دیگران قرض بدهیم، یا به امانت بسپاریم، و یا هدر بدهیم، به مردم ببخشیم و یا گران‌ترش کنیم. مطمئناً کسی هم هست که آن‌را از ما بدزدد! پس دقیقاً این واحد پولی هم همانند تمام پول‌های موجود است و تمام قوانینی که روی آن اعمال می‌شود در مورد این نیز صدق می‌کند با این تفاوت که برای بدست آوردن پول ریال یا دلار باید جان کَند. اما پول زمان، مفت و مجانی است.

ادامه مطلب در صفحه بعد…

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

نقش کارکنان فناوری اطلاعات در افزایش نرخ حوادث کاربران

کارکنان پشتیبانی میزخدمت مدام درگیر حل و فصل خرابی‌ها و حوادث مطرح شده توسط مشتریان یا کاربران هستند و خیلی زود در انتهای یک روز، انرژی و توان و پاسخگویی به آنها را از دست می‌دهند و هرگونه پیگیری کاربران نیز به مثابه‌ی “گیر دادن” آنها تلقی می‌شود و با ترفندهایی نظیر بستن درخواست بدون اطلاع و تایید کاربر، ایجاد پروسه‌ی بیشتر برای رسیدگی، نادیده گرفتن درخواست‌های آنان، وعده دادن، پاسکاری درخواست به همدیگر و….سعی می‌کنند به نحوی از زیر بار فشار پیگیری و انجام وظایف شانه خالی کنند. تقصیری هم ندارند زیرا این دسته از افراد واسط بین سرویس‌دهنده و کاربران هستند. یک پل ارتباطی که اگر پایه‌های آن محکم و استوار ساخته نشده باشد اولین کامیونی که از روی آن رد شود باعث ریزش پل خواهد شد!

مشکل کجاست؟

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

این یعنی این واحد، یک سرویس‌دهنده است و هر کدام از این زیرساخت‌ها جزو سرویس یا خدمت محسوب می‌شوند سرویس‌ها به دو روش در اختیار قرار می‌گیرند: الف- درخواست سرویس جدید ب- ثبت خرابی روی سرویس ارایه شده. تا اینجا همه چیز گل و بلبل است. چندصد میلیون تومان خرج تهیه‌ی تمام زیرساخت‌های فناوری شده و چند ده نفر متخصص هم برای ارایه‌ی سرویس‌های مختلف نیز به کار گرفته شده و یک ویترین از آدم‌ها نیز تحت عنوان کارکنان پشتیبانی هلپ‌دسک، نقش پل ارتباطی بین کاربران و سرویس‌های زیرساخت را ایفا می‌کنند.

اما علیرغم چینش درست همه‌ی این آیتم‌ها، باز خرابی‌ها در اوج خود رخ می‌دهند و حجم مشکلات بجای کاهش، رو به فزونی است! همین می‌شود که در مدت کوتاهی نیروهای میزخدمت دلزده و افسرده می‌شوند و بسیاری بی‌هیچ انگیزه‌ای ترک سازمان می‌کنند. زیرا حجم خرابی‌ها و مشکلات به حدی است که توان خلاقیت و فکر کردن از آنها را می‌گیرد و آنها حتی علیرغم چندین سال تجربه و خدمت در سازمان، مبدل به ربات‌هایی می‌شوند که هر روز و هر روز در حال خاموش کردن آتش‌اند!

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

بماند که حیات و زیست‌بوم چه حیواناتی از بین می‌رود! فرو نشاندن چنین آتشی تقریباً کاری غیرممکن به نظر می‌رسد. بنابراین اگر سال‌ها درختانی در روز نهال‌کاری کاشته‌ایم به امید زمین پاک! کار خوبی کرده‌ایم اما اگر برای حفاظت از جنگل برنامه‌ای نداریم، فرهنگ‌سازی نکردیم و به‌راحتی یک نادان، بصورت عمدی کبریتی بر جان طبیعت می‌اندازد و در آخر هیچ ابزار کارآمدی برای فرونشاندن فوری آن نداریم، نشان می‌دهد اصول جنگلداری را بلد نیستم!

اگر فناوری اطلاعات را یک جنگل در نظر بگیریم پس هر سرویس یک درخت است! حافظان دلسوز طبیعت، کارکنان پشتیبانی لایه‌ی پیشخوان هستند و هواپیما و کپسول و بیل و خاک، راهکارهای حل مشکل‌اند. راهکارهای شناخته شده برای مشکلات شناخته شده! اما وجود علف خشک در سطح زمین و باد موافق آتش، مشکلات ناشناخته است و به واقع برخورد با آن چندان امکانپذیر نیست. خُب چکنیم با چند بیل و چند تشت آب برویم سراغ آتش!؟

پاسخ، بله چون آتش در حال پیشرفت است!

نتیجه: سوختن اکثر درختان، آسیب دیدن حافظان طبیعت

اما پیش از این چه باید می‌کردیم که به این روز نیافتیم؟

باید ببینم چه کسی و چه چیزی این آتش را به راه انداخته و چرا!؟

چهار علت طبیعی اصلی برای آتش‌سوزی جنگل عبارتند از: آذرخش، فوران آتشفشانی، جرقه در اثر فروافتادن صخره‌ها و احتراق خودبخود اما دخالت و فعالیت‌های انسانی نظیر: روشن کردن آتش برای جوجه کباب و چایی ذغالی! جرقه‌های ماشین‌آلات و ته‌سیگارهای دورانداخته‌شده و آتش‌زدن بقایای محصولات کشاورزی بعنوان علل عمدی همیشه مطرح می‌شود!

خُب علل طبیعی در جنگل فناوری امری قابل درک است. ممکن است هر اتفاقی منجر به از کار افتادن سرویس شود. برخی از آنها بطور پیشگیرانه قابل حل‌اند و برخی منفعلانه. بحث مهم ITIL در زمینه‌ی مدیریت حادثه نیز برای همین دسته از خرابی‌های طبیعی است.

اما خرابی‌های عمدی نه! خرابی‌های عمدی توسط حافظان طبیعت اتفاق نمی‌افتند بلکه دقیقاً توسط مدیران و کارشناسان زیرساخت رخ می‌دهند که مهمترین علت آن انجام بسیاری از تغییرات ناآگاهانه و بدون مدیریت صحیح تغییر است که منجر به شعله‌ور شدن آتش و افزایش نرخ خرابی می‌شود.

مثال‌هایی از علل وقوع خرابی‌های طبیعی در فناوری اطلاعات می‌تواند مواردی نظیر: سوخته شدن پاور یک سیستم، کنده شدن سوکت کابل شبکه، هنگ کردن سرور، اتمام کارتریج پرینتر، عدم آموزش کاربر و … باشد

و علل عمدی می‌تواند شامل: تغییر پورت وب یک نرم‌افزار تحت وب، تغییر دسترسی به نرم‌افزار، انجام پالیسی‌های امنیتی جدید، تغییر منابع سخت‌افزاری یک سرور، تغییر روش ورود به فلان نرم‌افزار، تغییر سناریو پرینت سرور و….

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

در ITIL تمرین مدیریت حادثه یا Incident Management برای رفع رجوع همین موارد مطرح شده. هدف آن ثبت و رسیدگی به حوادث و به حالت نرمال درآوردن تغییر وضعیت یک سرویس معیوب به یک سرویس سالم است. اما باید دقت داشت که اگرچه این تمرین برای هر نوع علت خرابی اعم از عمدی یا طبیعی می‌تواند به کار گرفته شود اما ماهیت درست آن رسیدگی به علل طبیعی خرابی سرویس‌هاست.

پس شک نکنید اگر جلوی تغییرات ناآگاهانه، را نگیرید باعث و بانی تمام این خرابی‌ها و شعله‌ور شدن آتش به جان جنگل شمائید! پس بدون بررسی دقیق، بدون برنامه‌ی پشتیبان، بدون ارزیابی ریسک و خطرات آن و بدون اطلاع‌رسانی انجام هر تغییری یک امر غلط است و کسی که با نظر شخصی یا تصمیم فوری و بدون ملاحظه! مصّر به انجام آن است یعنی عمداً می‌خواهد آتشی برپا کند!  تردید نیست در اینصورت با صدها نیروی پشتیبان نیز از پس حجم خرابی‌ها برنخواهید آمد. بنابراین رویکرد مهم فناوری اطلاعات برای پرهیز از این موضوع استفاده از مدیریت تغییر صحیح است!

البته این بدان معنا نیست که از ترس وقوع خرابی، هیچ تغییری را انجام ندهیم خیر! باید با تمرین مدیریت تغییر که با هدف انجام تغییر با حداقل ریسک است می‌توان نرخ حوادث ناشی از انجام تغییر را به حداقل رساند. این یعنی باید تغییر آگاهانه باشد، اطلاع‌رسانی شود، برنامه‌ی پشتیبان داشته باشد، طبق زمان‌بندی باشد، در بازه‌ی زمانی اتفاق بیفتد که کمترین اثر را روی سایر خدمات و کاربران بگذارد. به عبارتی باعث خرابی‌ها تغییرات نیستند بلکه اهمال‌کاری واحد فناوری اطلاعات در خصوص عدم بکارگیری مدیریت تغییر و انجام تغییراتی است که منجر به خرابی انبوه می‌شود. اگر این نکته‌ی کلیدی را رعایت کنید نشان می‌دهد اصول جنگل‌داری را بلدید این اصول در فناوری اطلاعات همان ITIL است!

فراموش نکنید هیچ تغییری را کوچک نشمرید! یک تغییر به‌ظاهر کوچک می‌تواند منجر به فاجعه شود! همچنان که یک ته‌سیگار می‌تواند جنگلی را به آتش بکشد!

هادی احمدی

نوشته باعث بیشتر خرابی‌ها خودِ واحد فناوری اطلاعات است! اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

دیوار بزرگ چین در فناوری اطلاعات سازمان

هرگاه مستقیماً درگیر یک سازمان اسم و رسم‌دار می‌شوم چیزهای آزار دهنده‌ای را می‌‌بینم که بعنوان یک نویسنده، فعال فناوری اطلاعات و مدرس ITIL قادر به چشم‌پوشی از آنها نیستم. هرچند همواره سعی‌ام بر این است بجای نقد، ارزیابی درستی داشته باشم تا اینکه با نگاهی از بیرون (Outlook) مجموعه‌ای از مشاهدات، تجربیات و پیشنهادات فنی را در نقلی داستان‌وار مطرح کنم تا شاید تلنگری باشد ابتدا به خودم، بعد به آن سازمان و در غایت به سازمان‌های مشابه، جهت یادگیری بیشتر و هماهنگ شدن با فرهنگ فناوری و مفهوم تحول دیجیتال و برای رسیدن به بهبود مستمر.

دیتاسنترها و زیرساخت فناوری

یک قاعده‌ی کلی در اکثر مراکز داده‌ی کشور، به شدت مشترک است: تکیه بر زیرساخت سخت‌افزاری با تنوع تجهیزات، هزینه‌های سنگین، تنوع برند، تنوع روش‌های نگهداری است. بجای تمرکز بر فرهنگ‌سازی، بهره‌گیری از روش‌های مهندسی خرید، استفاده از چارچوب‌های مدیریتی. این یعنی دیتاسنترها یا مراکز داده‌ای کشور، هر کدام‌ یک مخزن از هزینه‌های میلیاردی و تجهیزات گران‌قیمت‌اند اما بدون یک استراتژی نرم که تنها یادآور کننده‌ی روایت زیر است:

دیوار بزرگ چین، بزرگترین دیوار جهان است. دژی به طول ۲۱۰۰۰ کیلومتر همراه با ۲۵۰۰۰ برج نگهبانی با قدمت ۲۳۰۰ سال پیش. با بیشترین هزینه، بالاترین تعداد منابع انسانی بکار گرفته شده، بهترین مصالح و در مدت طولانی برای جلوگیری از حمله مغول‌ها. اما علیرغم همه‌ی اینها، مغول‌ها بارها به چین حمله کرده‌اند. هیچ‌کدام از پادشاهان با ساخت دیوار به هدف خود نرسیدند. چون دیوار در جاهای زیادی شکست و مغولها فرصت یورش به چین را پیدا کردند. از دیوار گذشتند بی‌آنکه از آن بالا بروند یا آنرا تخریب کنند. آنها با پرداخت رشوه به نگهبانان برج‌های نگهبانی این دیوارها، خیلی ساده به گنج‌های آنسوی دیوار، دست پیدا ‌کردند. این حکایت دقیقاً مصداق زیرساخت‌های مراکز داده و یا کلیه‌ی خریدهای اکثر سازمانهای کشور است که صرفاً متکی بر ابزار است.  با این تصور که چنین زیرساختی سازمان را به اهداف مورد نظر خواهد رساند. اما ناگفته پیداست که جدای از رانت‌هایی که این وسط برای خرید و تجهیز مراکز داده وجود دارد از هیچ روش مدیریتی برای نگهداشت و بهبود آن استفاده نمی‌شود و تماماً خریدها مقطعی و بدون برنامه‌ریزی  بلندمدت برای تامین نیازهای سازمان است و بخوبی روشن نیست اهمیت وجود آنها و ارزشی که قرار است تولید کنند چه هست!؟ بنابراین حلقه‌ی مفقود شده، همیشه فرهنگ‌‌سازی، تدوین سیاست‌ها، روش‌های استاندارد مدیریتی کارآمدست که سبب خلق نتیجه‌ی مطلوب می‌شود.

• اگر یک َرک بالا‌ بلند! با دهها سرور و سوییچ خریداری و پیاده‌سازی کرده‌اید اما ابزاری برای مدیریت امنیت آن، مدیریت دسترسی، گزارش‌گیری، کنترل و نظارت مستمر و دائم برای آن در نظر نگرفته‌اید یا موقت در نظر گرفته‌اید. همان داستان دیوار چین را تداعی کرده‌اید.
• اگر برای رشد سازمان یک ابزار گران‌قیمت ITIL‌ را خریده‌اید اما همچنان Business As Usual کار می‌کنید. داستان دیوار چین را تکرار کرده‌اید.
• تجهیزات، ابزارها و اتوماسیون‌ها همگی خوب هستند و گره‌گشای بسیاری از مشکلات. اما اگر قبل از اینکار و پشت بندش، تحول دیجیتال در نظم فکری مدیران و کارکنان نباشد و به همان شیوه‌ی مرسوم ادامه دهند و روش مدیریتی و حمایت انسانی را نداشته باشد باز دیوار چین را ساخته‌اید.
• دقت کنید ساخت دیوار چین یک خروجی است اما شکسته شدن یا نشدن آن نتیجه است! و نتیجه مهمتر از خروجی است.
• اگر هر سال بدنبال جذب یک پیمانکار با کمترین قیمت هستید اما کاری برای کاهش ترافیک خرابی‌ها و تلاشی برای بهبود نشده، فقط آجر رو آجر گذاشته‌اید! آنهم با کارگران ارزان و دستمزد کم.

پس مهم داشتن تجهیزات صرف نیست مهم ابزارهای گرانقیمت نیست مهم یکپارچگی است مهم یکدست شدن و مهم فرهنگ‌های مدیریت و روش‌های نظارتی است. بنابراین به تعداد سرویس‌ها و تجهیزاتی که خریداری شده باید به همان اندازه نیروهای انسانی بهتری را با روش‌های مدیریتی برای نگهداشت آنها تربیت کرد.

نباید هر سال هزینه‌ی نگهداری خدمات افزایش یابد! بلکه برعکس باید کمتر شود حتی اگر حداقل دستمزدها افزایش کرده باشد این یعنی شما با بهره‌گیری از بهترین تمرینات و بهبود مستمر، هزینه‌های انجام خدمت را باید توانسته باشید کاهش دهید. بدون داشتن برنامه‌ی خلق ارزش، خرید و تجهیز مراکز داده، فقط آجر روی آجر گذاشتن است برای بالا رفتن یک دیوار بلند دور خودمان!

هر سرویسی دارای چرخه‌ی حیات است حیاتش باید تضمین شود(ITIL3) اما هر سرویس دارای زنجیره‌ی ارزش خدمت است یعنی باید ارزشی را تولید کند تا بقای کسب و کار رقم بزند!(ITIL4)

نگهداری از یک سرویس یعنی گارانتی حیات و سلامت آن. جدای از اینکه سازمان‌ها بدنبال چه ارزشی هستند بیشتر تمرکزشان روی حیات سرویس متمرکز است یعنی همینکه زنده بماند و خاموش نشود کفایت می‌کند! برای این مهم حضور برخی کارشناسان خودی و یا پیمانکار را الزامی می‌دانند تا شبیه پرستارانی روی بالین بیمار حضور داشته باشند تا اگر تب و لرزی اتفاق افتاد دستمال نمناک مرطوبی را روی سرش بگذارند!

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

ادامه مطلب در صفحه بعد…

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

الگوریتم مدیریت خدمات و مولفه‌های خدمت

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

مثلاً کسی که می‌خواهد برنامه‌نویسی یاد بگیرد بین پلتفرم‌های مختلف گیر می‌کند و نمی‌تواند انتخاب درستی بکند. اما به‌واقع اینجا بحث انتخاب درست یا نادرست نیست بلکه درک شما از ساختار برنامه‌نویسی اولویت و اهمیت بالاتری نسبت به انتخاب محیط برنامه‌نویسی دارد. این یعنی زمانی‌که بعنوان یک برنامه‌نویس یا توسعه‌دهنده می‌خواهید فعالیت کنید مهمتر از انتخاب زبان برنامه‌نویسی، قدرت تجزیه و تحلیل شماست و درک شما از الگوریتم کار است به‌عبارتی زمانی که شما الگوریتم را آموخته باشید زبان‌های برنامه‌نویسی فقط دارای Syntax هایی متفاوتی هستند که براحتی با صرف زمانی بسیار اندک، می‌توانید الگوریتم خود را در آنها پیاده کنید.

در بحث مدیریت فناوری اطلاعات و یا مدیریت خدمات سازمانی، نگهداری و پشتیبانی شبکه نیز همین داستان هست یعنی سرگردانی متخصصین شبکه بین تخصص‌ها و ابزارهای مختلف برای مدیریت آنها به همین شکل بحث‌ برانگیزست.  اینجا نیز همین چالش مطرح است اما دقیقاً همین‌جا هم ردپای یک الگوریتم دیگر در میان است. ITIL در حقیقت یک الگوریتم تمرین شده و موفق است که ذهنیت مدیریتی به شما خواهد داد. این یعنی کافیست شما مفهوم مدیریت خدمات بر مبنای به‌روش‌های ITIL را بلد باشید پس از آن خیلی ساده با هر ابزاری قادر به پیاده‌سازی و یادگیری سریع آن خواهید بود. اما اگر این مفاهیم را بلد نباشید هر محیط و هر ابزاری آن چیزی نیست که شما را به موفقیت برساند آنچنان که گریدی بوچ مهندس نرم‌افزار اهل آمریکا می‌گوید:”احمق با یک ابزار باز احمق است!” این یعنی اگر مفهوم قضیه را خوب درک نکرده باشید با هر ابزاری که در اختیارتان باشد باز ناتوان هستید.

ابزارهای مدیریت فناوری اطلاعات و پلتفرم‌های برنامه‌نویسی، جدای از کاربرپسند بودن، داشتن قابلیت و امکانات مختلف، تماماً بر مبنای مفاهیم پایه استوار هستند. شکی نیست به همین دلیل است که در دانشگاه‌های بجای آموزش ابزار و محیط و پلتفرم، مبانی و Concept را به دانشجویان آموزش می‌دهند چراکه این باور درست است که اگر کسی این مبانی و مفاهیم را بخوبی درک کرده باشد براحتی استفاده از هر ابزاری برایش مقدور خواهد شد.

مبانی و مفاهیم بنیادی معمولاً یک دانش تئوریک و یا نظری است. از طرفی کار عملیاتی با یک ابزار، دانش عملی است. باید خوب بدانید که بدون دانش نظری، شما نمی‌دانید قوانین رانندگی چیست و بدون تجربه‌ی عملی، هرگز راننده نخواهید شد. دانش نظری، تمام پاسخ ها را در رابطه با “چرا” به شما می‌دهد، و دانش عملی تمایل دارد که شما را از “چگونگی” آگاه کند. بنابراین چه متخصص شبکه باشید چه برنامه‌نویس، قدم اول به دنبال انتخاب پلتفرم نباشید.

پس از یادگیری الگوریتم کار، اکنون نوبه‌ی انتخاب پلتفرم یا ابزارست تا به واقع به هدف غایی خود در موفقیت شغلی برسید. این موضوع برای تمامی زمینه‌های شغلی صدق می‌کند و آنرا به همه جا تعمیم دهید نتیجه همین است!

مبانی ITIL چیست؟

در نسخه ITIL4، از چرخه‌ی حیات خدمت به سمت زنجیره‌ی ارزش خدمت رسیدیم از فرایند به تمرین. این یعنی چه؟

چرخه‌ی حیات را اگر به طول عمر و یا زمان زندگی کردن تعبیر کنیم به این نکته می‌رسیم که هدف بقاست یعنی تحت هر شرایطی خدمت یا زندگی ما باید حفظ شود تا معنای وجود داشتن ما را برساند. اینجا مهم است که ما صدسال زندگی کنیم!

اما در زنجیره‌ی ارزش، به عرض زمان اشاره می‌کند یعنی کیفیت عمر و اینکه از ماحصل زندگی کردن ما بعنوان یک انسان چه رسالتی مورد انتظار است ما برای چه هستم و هدف از ۱۰۰ سال زندگی کردن چه ارزشی به همراه دارد؟

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

وقتی یک خدمت طراحی می‌کنید که خرابی‌های پرینتر را پوشش دهد یعنی قصد دارید تا ارزش منفی (تاثیر بد خرابی‌ پرینتر در کسب و کار) را بدست آورید هرچند خدمات مربوط به پشتیبانی و خرابی در ظاهر ارزش مثبت خلق نمی‌کند اما شکی نیست کاهش ارزش نرخ خرابی یعنی کاهش ارزش منفی و کاهش ارزش منفی نیز یعنی ارزش مثبت

اما چگونه؟ زمانی که می‌خواهید عادت‌های خوب داشته باشید یعنی خلق ارزش مثبت و اما زمانی‌که سعی می‌کنید عادت‌های بد را از بین ببرید یعنی کاهش ارزش منفی. بنابراین چه سعی کنید کارهای خوب بکنید و چه اینکه از کارهای بدی که می‌کردید جلوگیری کنید در هر صورت شما آدم خوبی هستید!

ادامه مطلب در صفحه بعد…

نوشته الگوریتم مدیریت خدمات و مولفه‌های خدمت اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

بهبود مستمر در ITIL چیست و چطور آنرا پیاده‌سازی کنیم؟

اینکه چقدر خوب هستیم چندان اهمیتی ندارد بلکه چقدر می‌توانیم بهتر باشیم مهم است! هدف اصلی مدیریت خدمات فناوری اطلاعات (ITSM) ارائه‌ی بهترین خدمات ممکن با کمترین هزینه ممکن است، در عین حال ارزش‌بخشی به مشتریان. اما، در حالی که سازمان‌های ITSM-گرا به طور کلی می‌توانند با مفهوم “بهترین خدمات ممکن” و “کمترین هزینه‌ی ممکن” کنار بیایند، نیل به “ارزش” هنوز آرزویی به‌ظاهر دست‌نیافتنی است گویی رویایی است که با رمز و راز پوشانده شده. از آنجا که بخش بهبود مستمر خدمات (CSI) چرخه‌ی حیات خدمات همه چیز درمورد (هم تراز کردن) خدمات با تجارت است – اما متاسفانه، ارزش این فرایند کلیدی (بهبود مستمر)- در هنگام اجرای اصول ITSM اغلب نادیده گرفته می‌شود یا حتی از آن چشم‌پوشی می‌شود.

مدیریت خدمات در سازمان‌ها، همواره تنها چیزی است که به‌طور مداوم با توجه به رضایت مشتری و هزینه‌ی خدمات، برای بهبود، افزایش کارایی و حداکثر اثربخشی به چالش کشیده می‌شود. بدون رویکرد ساختاری، اکثر فناوری اطلاعات سازمان‌ها فقط زمانی به فکر بهبود می‌افتند که اتفاقی ناگوار بر دسترسی یا عملکرد سرویس یا رضایت مشتری تأثیر گذاشته باشد به‌عبارتی تا زمانی که فاجعه‌ای رخ ندهد خبری از بهبود نیست! هرچند که، CSI مکانیسم‌هایی برای بهبود مستمر، حتی جلوگیری از وقایع فاجعه‌بار که ممکن است بر رضایت مشتری، در دسترس بودن خدمات (غیر) و تأثیرات مالی منفی تأثیر بگذارد، ارائه می‌دهد. اما مهم است که درک کنیم CSI فقط به مدیریت سازمان یا قسمت خاصی از چرخه‌ی حیات خدمت وابسته نیست. بلکه CSI تمام جنبه‌های ITSM سازمان و کل چرخه‌ی خدمات را تا خلق ارزش پوشش می‌دهد و این یعنی بهبود مستمر ۷ مرحله‌ای سنگ بنای CSI است.

فرایند بهبود مستمر ۷ مرحله‌ای در یک حلقه‌ی مدور به هم ارایه شده است. که با پیروی از این حلقه، خروجی هر مرحله‌ی ورودی داده‌ای برای مرحله‌ی بعدی است و این چرخه‌ی مدور تا بلوغ ارایه‌ی خدمات همواره در چرخش است

بیایید مراحل فرآیند بهبود ۷ مرحله ای را بررسی کنیم:

۱- چه چیزی را باید اندازه بگیرید؟

تا ندانید چه چیزی را باید اندازه بگیرید نمی‌توانید بهبودی هم داشته باشید. این یعنی بدون اندازه‌گیری نمی‌توانید مدیریت کنید. با اشراف بر هر قسمت از چرخه‌ی حیات سرویس، پیش از تدوین استراتژی خدمات و طراحی خدمات باید از قبل پاسخ این پرسش‌های را بدانید و باید نقاط شروع را مشخص کرده باشید. در چنین شرایطی، نقش CSI این است که این پرسش را مطرح کند: “اکنون کجاییم؟” این مرحله‌ قبل از شروع مجدد چرخه است یعنی نقطه‌ی صفر آغاز است پس باید شما بدانید کجای داستان ایستاده‌اید. شناسایی نقطه‌ی الف (مبداً حرکت شما).

سناریو: فرض کنید می‌خواهید در ارایه خدمت چاپ و پرینت در سازمان بهبود حاصل کنید. پس می‌دانید چیزی که که باید بهبود دهید خدمت چاپ است. این یعنی نقطه‌ی الف.

۲- چه چیزی را می‌توانید اندازه بگیرید؟

هر سازمانی ممکن است محدودیت‌هایی هم در مورد اندازه‌گیری واقعی داشته باشد. می‌توانید با شناسایی نیازهای جدید سطح خدمات، قابلیت‌های فناوری اطلاعات از طریق شناسایی، طراحی سرویس‌ها و پیاده‌سازی فرایند انتقال سرویس، بودجه‌های موجود، تجزیه و تحلیل فاصله رسیدن به معیارها و شناسایی فرصت‌های پیشرفت را انجام و همچنین به این پرسش پاسخ دهید که: “چگونه به آنجا برسیم؟”. این یعنی شناسایی نقطه‌ی ب (مقصد حرکت شما).

با ترسیم یک نقشه‌‌ی راه قادر خواهید بود تا به این نتیجه برسید که منظور شما از بهبود خدمت چاپ چیشت؟ آیا کاهش نرخ مصرف کارتریج است یا کاغذ یا برق یا همه‌ی اینها.

۳- داده‌ها را جمع‌آوری کنید.

پس از آنکه مبدا و مقصد را مشخص کردیم به منظور پاسخ مناسب به “آیا ما به آنجا رسیده‌ایم؟” داده ها ابتدا باید جمع‌آوری شوند (معمولاً از طریق عملیات سرویس). جمع آوری داده‌ها مستلزم داشتن نوعی نظارت در محل است. نظارت را می‌توان با استفاده از فناوری مانند برنامه‌ی گزارشگیری که معمولاً در ابزارهای ITSM هست، ابزار نظارت بر سیستم و مولفه‌ها یا حتی یک فرایند دستی برای کارهای خاص اجرا کرد. داده‌ها بر اساس اهداف و اهداف شناسایی شده جمع‌آوری می شوند. در این مرحله، داده‌ها خام هستند و نتیجه‌ای حاصل نمی‌شود.

در این حالت مدیریت رخداد، مدیریت مشکل و مدیریت تغییر می‌تواند داده‌های لازم را در اختیار شما بگذارد. مثلاً نرخ خرابی پرینترها، نرخ درخواست کارتریج و…

ادامه مطلب در صفحه بعد…

نوشته چگونه فرایند بهبود مستمر را در ۷ مرحله انجام دهیم؟ اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

هفت R در مدیریت تغییر

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

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

در اینجا سوالاتی وجود دارد که نویسندگان همه سازمان های فناوری اطلاعات را به پاسخ می‌کنند:

۱. چه کسی تغییر را ایجاد[۱] کرده است؟

آفت مزرعه انفورماتیک، ملخ نیست! بلکه سیل تغییر غیرمجاز آفت فناوری اطلاعات است. متاسفانه بسیاری از مدیران انفورماتیک، کارشناسان و تکنسین‌ها حسب درخواست‌های کاربران و یا در جهت اصلاح یک سری خدمات اقدام به انجام تغییرات خودسرانه می‌کنند بی‌آنکه آنرا جایی ثبت و ضبط کنند این تغییر غیرمجاز که روند صحیح مدیریت تغییر را در خود ندارد علاوه بر افزایش بار ترافیکی ناخواسته، سبب کاهش کیفیت ارایه‌ی خدمات می‌شود بنابراین در مدیریت تغییر لازم‌است که یک تغییر ابتداً ثبت شود زیرا با وجود بسیاری از نقاط ورود، ذینفعان، تنوع سرویس‌ها و منابع سرازیر شدن سیل تغییرات امری اجتناب ناپذیر است پس جای تعجب نیست که این پدیده، خود منجر به بروز مشکلات فراوانی خواهد شد. یکی از راه‌های اجرا و رسیدگی به تغییرات مجاز، ایجاد سیستمی و متمرکز تمام تغییرات است. چنین سیستمی باید کنترل‌های مناسبی را برای حل تغییرات در مناطق عملیاتی در اختیار داشته باشد. این “سیستم ثبت” ویژه و منفرد، در هنگام ممیزی‌ها بسیار مفید است. در نتیجه اولین R کلیدی در مدیریت تغییر، ثبت تغییر توسط درخواست‌کننده‌ی آن است.

۲. دلیل[۲] تغییر چیست؟

دلیل تغییر[۳] بیانگر هدف نهایی از ایجاد یک درخواست تغییر است. به‌عنوان مثال، اگر یک چاپگر در سازمان شما به دلیل آسیب‌دیدگی یا اتمام کارتریج کار نکند، دلیل تغییر می‌تواند کار نکردن پرینتر باشد بنابراین درخواست تغییر ایجاد شده، می‌تواند کارتریج چاپگر را تغییر دهد. به همین ترتیب، می‌توانید بیشترین دلایل آغاز درخواست تغییر را در همه‌ی زمینه‌های ارایه‌ی خدمت، ثبت کنید. این به مدیریت فناوری اطلاعات کمک می‌کند تا گزارش‌هایی را در مورد دلایل ایجاد تغییر در سازمان بدست آورد و ارزیابی بهتری نسبت به حجم و دلایل تغییرات را داشته باشد. ثبت و درک دلیل تغییر، سبب می‌شود در میان‌مدت علت نیاز به تغییرات را کاهش دهید…و گامی در جهت بهبود مستمر و کاهش نرخ تغییرات تکراری بردارید. از طرفی با شناخت علت تغییر از ریسک‌هایی که این تغییر ممکن است ایجاد کند می‌توانید جلوگیری کنید. در حقیقت، بدون پاسخ روشنی به این پرسش که علت تغییر چیست، نوآوری‌های استراتژیک به راحتی در سیل بی‌وقفه‌ی تغییرات تاکتیکی قرار می‌گیرد و چشم‌انداز و هدف‌گذاری اثربخشی تغییرات را از بین می برد بخصوص آنکه از آن‌جایی که تا حدود ۷۵ درصد بودجه فناوری اطلاعات  به حفظ زیرساخت‌های قدیمی اختصاص دارد. صرف‌نظر از نوع تغییر‌، هر تغییر عمده باید بر اساس معیارهای تجزیه و تحلیل نمونه کارها مورد توافق‌شده، ارزیابی شود. این ارزیابی، اولویت‌بندی مناسب تغییرات را تضمین می‌کند و قبل از هدر دادن منابع، ناهماهنگی بالقوه و ناخالص را آشکار می‌کند. در نتیجه دومین R کلیدی در مدیریت تغییر، ثبت علت تغییر توسط درخواست‌کننده‌ی آن است.

۳. چه بازگشتی[۴] از تغییر مورد نیاز است؟

نتیجه‌ی کسب شده از تغییر به‌ویژه در بازگشت هزینه‌های مالی‌ کمک می‌کند تا اولویت تغییرات استراتژیک و پروژه محور را به‌خوبی درک کنید. ITIL دو ورودی کلیدی را در روند مدیریت تغییر (مشکلات و نوآوری) می‌شناسد‌، اگرچه راهنمایی خوبی در مورد چگونگی تنظیم نوآوری ارایه نمی‌کند اما “مدیریت مالی ITIL برای خدمات فناوری اطلاعات” می‌تواند اطلاعات مفید مربوط به هزینه را ارائه دهد هرچند برای سنجش عینی تأثیر واقعی هزینه‌های مالی تغییر باید آن تغییر را بر اساس معیارهای مبتنی بر ارزش تکمیل کرد. به‌عبارتی دیگر توجیه مالی اجرای یک تغییر باید موجه باشد و در راستای بازگشت هزینه‌ها و یا کنترل هزینه‌ی تغییرات باشد وگرنه پرداختن به هر تغییری بدون بررسی آورده‌ی مالی و ارزش ریالی آن در درازمدت بار مالی هنگفتی بر دوش سازمان می‌گذارد که توجیه‌پذیر نخواهد بود. در نتیجه سومین R کلیدی در مدیریت تغییر، درک بازگشت هزینه‌های مورد انتظار است.

ادامه مطلب در صفحه بعد…

نوشته هفت R در مدیریت تغییر اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

آندون در مدیریت فناوری اطلاعات

“Andon” یا آندون یک اصطلاح ژاپنی است و تعریفی از یک فانوس کاغذی سنتی، که کاغذ آن از چوب بامبو ساخته شده است و از طریق یک منبع نورانی (مثل شمع) روشن می‌شود. در مدیریت تولید از این واژه، تولیدکنندگان ژاپنی جهت کنترل کیفیت محصولات خود بهره گرفتند.

مثلاً شرکت تویوتا از این مفهوم در کلیه‌ی ایستگاه‌های خط تولید خود استفاده کرد این یعنی در دسترس هر کارگری یک فانوس آندون هست که هرکسی می‌تواند ریسمان آندون Andon Cord را بکشد (یا دکمه‌ای را فشار دهد) و خط تولید را متوقف کند اینکار برای نشان‌دادن این است مشکلی حادث شده و یک سری اقدامات درمانی و اصلاحی باید صورت گیرد و این امکان را می‌دهد تا پیش از شروع مجدد تولید، مشکل حل شود. با آندون، اگر چیزی نادرست باشد، نیازی به کسب تکلیف و یا دریافت فرمان سلسه‌مراتبی نیست و هر کارگر در خط تولید، با هر تجربه و سطح دستمزدی که داشته باشد، حق دارد ریسمان را بکشد. ریسمان آندون به عنوان یکی از عناصر روش کیفیت Jidoka توسعه یافته و با کمک آن تویوتا و سیستم تولید تویوتا، به کارگران این امکان را می‌دهد تا به همکاران و مدیریت مشکلات کیفیت و فرآیند در سراسر مونتاژ اطلاع دهند و حتی تولید را متوقف کنند.

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

آندون نشان‌دهنده‌ی درجه‌ای از استقلال فردی در یک سیستم است برای جلوگیری از پیامدهای ناخوشایندتر! این مفهوم امروزه از کنوانسیون‌های صنعتی فراتر رفته. این استقلال یکی از بلوک‌های ساختاری فرهنگی تولید ناب است. در دنیای فناوری اطلاعات نیز افرادی که به‌دنبال درک چارچوب‌های ITIL،   Lean IT و یا DevOps باشند، مهم است که این موضوع را بشناسد.

همچنان که آندون یکی از نمادهای صنعتی در تولید ناب است، جلسه‌ی هیئت مشاورین تغییر ITIL (CAB) برای بسیاری از افراد در DevOps نیز نمادی قدرتمند برای ITSM است.

هدف اصلی تیم‌های DevOps ایجاد تعداد بالای نسخه‌های تولیدی قابل اعتماد که همواره روندی افزایشی در پی دارد و جلسه CAB اغلب به عنوان پادزهر این امر تلقی می‌شود، که بسیار مناسب هم هست و جلوی تولید و تغییرات ناخواسته را می‌گیرد اما گاهاً فرایند بررسی و تصویب تغییر در تولید یک روند دشوار و زمانبری ایجاد می‌کند و ممکن است کسب اجازه‌ی تغییر پس از صرف‌کردن زمان زیاد در جلسات، حدود یک یا دو هفته زمان نیاز داشته باشد. همین موضوع سبب ناراحتی تولیدکنندگان DevOps‌ می‌شود، که از نظر آنها فرایند تایید در کمیته CAB تا حدی ناعادلانه است. دلایل آنها نیز گاها درست است. خوشبختانه، ITSM در طی سالیان متمادی تفکر خود را متحول کرده و تلاش زیادی برای تطبیق نیازهای DevOps با ITIL انجام داده. به عنوان مثال: داشتن بررسی CAB برای هر درخواست تغییر، کارآمد نیست و قطعاً منطقی هم نیست. دعوای DevOps و ITIL را از لینک زیر بخوانید.

با این وجود، داشتن درخواست بررسی CAB در مورد ریسک ناشناخته، هنگامی که افراد و ذینفعان بیشتری ممکن است تحت تأثیر این تغییر قرار بگیرند، اهمیت و ضرورت پیدا می‌کند این یعنی بسته به ریسک تغییر، مفهوم کاربردی آن بیشتر به‌چشم می‌آید.

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

بیاید کمی بازترش کنیم. مفهوم Andon Cord شامل استفاده از سیگنال‌ها و هشدارها برای نشان‌دادن این است که یک ایستگاه در خط مونتاژ، مشکل دارد. هشدارها توسط کارگران با کشیدن ریسمان آندون یا به طور خودکار توسط خود تجهیزات فعال می‌شوند.

اگرچه ممکن است کشیدن ریسمان آندون برای متوقف‌کردن تولید، دیوانه‌کننده به‌نظر برسد، اما اگر این کار انجام نشود و نقصی پیدا شود و بلافاصله برطرف نشود، هزینه‌ای که برای رفع آن نقض متعاقباً باید پرداخت بسیار بیشتر خواهد بود و تأثیر شدیدی بر تجربه‌ی مشتری خواهد گذاشت. از طرفی به این نکته توجه کنید که کشیدن ریسمان آندون فقط برای رفع مشکلات نیست. به عنوان بخشی از یک برنامه بهبود مستمر، می‌تواند در جهت کمک به عرضه سرویس باکیفیت باشد. قسمت اعظم “قدرت کشیدن ریسمان آندون” به تیم‌ها برای ایجاد کیفیت در محصولات و فرایندها کمک بسزایی خواهد کرد به نحوی که تا وقتی تولید متوقف می‌شود، بهبود لازم آغاز گردد.

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

معمولاً تنها فرصتی که برای آزمایش و بررسی وجود نقص در نرم‌افزار هست پس از تولید نرم‌افزار است که در اواخر چرخه‌ی تولید و توسعه رخ می‌دهد. که صد البته این خیلی دیر است زیرا در واقع، این مشتریان خواهند بود که با ثبت اعلام خرابی، اکثر آزمایشات را انجام می‌دهند.

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

پس در هنگام داشتن خط تولید و نشر نرم‌افزار توقف تولید برای جلوگیری از نقص، مشکلات امنیتی در طی فرآیند توسعه واقعی، روال کاملی دارد که با استفاده از مفهوم آندون می‌تواند بهتر ارایه شود، اما چگونه؟

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

هرچند تولید محصول ناب زمان‌بر و هزینه‌بر است اما اگر با استفاده از کاربرد ریسمان آندون پیش برویم می‌توان هزینه‌های توسعه، تغییر و نگهداری پس از تولید را به حداقل رساند.

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

ITIL نظری یا کاربردی؟

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

متاسفانه رویه‌ی مدرک‌گرایی صرف، دوره‌های صرفاً تئوریک و نظری ITIL به شدت در  کشور رشد داشته غافل از آنکه ITIL نظری به تنهایی هیچ کمکی به استفاده از بهترین تمرینات در ارایه خدمات سازمانی برای خلق ارزش نمی‌کند و جز ارایه یک ذهنیت و داشتن یک برگ گواهینامه، عملاً صرفه‌ای برای سازمان به‌دنبال ندارد… و اگر به‌واقع بنگرید صرف‌کردن دهها میلیون تومان هزینه و چند ده ساعت وقت است!

امروزه اکثر مدیران فناوری اطلاعات و بسیاری از علاقمندان در پی حضور در دوره‌های آموزش چارچوب نظری ITIL  هستند در حالی عدم بهره‌کشی عملی از آنچه آموخته شده در دنیای واقعی سبب شده تا مفاهیمی پایه‌ای در حد همان مفاهیم باقی بماند…اگرچه داشتن مدارک کلیه سطوح ITIL تقویت رزومه‌ی افراد را جهت استخدام شدن را در پی خواهد داشت اما بدون تجربه‌ی عملی در پیاده‌سازی ITIL آنها درک درستی از چیزی که آموخته‌اند نخواهند داشت و دقیقا‌ به مانند دانشجویی هستند که تحصیلات دانشگاهی خود را تازه به اتمام رسانده باشد در حالی‌که هیچ درک درست و تجربه‌ی دقیقی از بازار و کسب و کار ندارد.

داشتن ابزار پیاده سازی و عملیاتی کردن مفاهیم نظری در فضای کسب و کار در حقیقت مفهوم واقعی ITIL‌ است که آنرا می‌توان ITIL کاربردی دانست بنابراین واحدهای آموزش سازمان‌ها و کارشناسان و مدیران فناوری اطلاعات باید به این نکته‌ی کلیدی توجه داشته باشند که صرف برگزاری دوره‌های ITIL موفق به حل مشکلات و نحوه‌ی ارایه‌ی خدمات بر پایه‌ی بهترین تمرینات جهانی نخواهند شد…

ITIL یک فرهنگ است اما اگر ندانید در عمل، این فرهنگ را با فضای کسب و کار سازمان چطور ترویج دهید، شما مروج فرهنگ نخواهید شد! این یعنی با ITIL نظری شما فقط مجموعه‌ای از واژگان جدید این چارچوب را آموخته‌اید نه چیزی دیگر…

از آنجایی که ITIL هرگز تبدیل به استاندارد نشد و در حد چارچوب باقی ماند بنابراین فاقد دستورالعمل‌های رایج در برخی استانداردهاست این یعنی همواره تمرینات آن با ساختار سازمان‌ها مرتبط است در یک کلام بهترین نتیجه برای پیاده‌سازی ITIL همسان‌سازی آن با سازمان است و سفارشی کردن آن، این‌گونه است که حتی ITIL پیاده سازی شده در یک سازمان هم به‌‌درد سازمان دیگری نخواهد خورد! پس ITIL را باید بصورت عملی تجربه‌ی کرد.

تجربه‌ی کاربردی و عملی ITIL به شما قدرت حرکت و اجرا می‌دهد شما را توانمند می‌کند تا در کنار مفاهیمی که فراگرفته‌اید قادر به پیاده‌سازی شیوه‌های تمرین شده باشید!

آنچنان که میشل دو مونتینی می‌گوید:”کسی بهتر از درسش استفاده می‌کند که آن را تکرار می‌کند، نه آن کسی که درس را حفظ می‌کند.” بنابراین تکرار درس‌های ITIL در فناوری اطلاعات سازمان‌ها امکانپذیر است تا آنچه که گفته شده را گوشت و پوست و استخوان خود حس کنید!

وقتی دانش به دست می آید، روشهای مختلفی برای دستیابی به آن داریم. این بخش‌ها شامل کتاب‌ها، سخنرانی‌ها، سمینارها، وبینارها، رویدادها، مسابقات و حتی آموزش است. در میان این موارد، کمتر کسی در طبقه دانش تئوری و دیگران تحت دانش عملی قرار دارد. مردم تمایل دارند دانش عملی را بیش از تئوری ترجیح دهند. بحث بر سر این نیست که کدام یک از لحاظ ماهیت از اهمیت بیشتری برخوردار است. در واقع، بحث در مورد این است که کدام یک از این دو مورد بیشتر از دیگری استفاده می‌شود و کاربرد عینی دارد.

بدون دانش نظری، شما نمی‌دانید قوانین رانندگی چیست و بدون تجربه عملی، هرگز راننده نخواهید شد. دانش نظری، تمام پاسخ ها را در رابطه با “چرا” به شما می دهد، و دانش عملی تمایل دارد که شما را از “چگونگی” آگاه کند.  

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

برای ساده کردن موضوع، هیچ دانش نظری یا عملی وجود ندارد، همه چیز مربوط به آموزش رسمی و خودآموزی است. که از آن تحت عنوان دانش سخت و دانش نرم می‌توان یاد کرد، هر دو دور از همند، شما هستید که باید یک پل قوی را بین هر دو پیدا کنید و بسازید و این پل همان تجربه‌ی پیاده‌سازی است و کمی شاعرانه‌تر تمرین تبر کردن با ریشه‌های خودتان است!

به قول یوگی بررا، “در تئوری، هیچ تفاوتی بین تئوری و عمل وجود ندارد. اما در عمل وجود دارد!”. و همچنین، “دانش هیچ فایده ای ندارد، مگر اینکه آنرا به کار ببندید و عملی بدون دانش عمیق هرگز امکان‌پذیر نیست”، همانطور که آنتون چخوف گفت. همه ما باید تعادل بین این دو نفر پیدا کنیم، بحث‌کردن هیچ فایده و پایانی ندارد.

طبق تجربه‌ی چندین ساله‌ در این حوزه، افراد بسیاری را دیده‌ام که با داشتن مدرک ITIL می اندیشند که هر آنچه که باید را آموخته‌اند در حالی‌که بسیاری فقط با واژه‌ها بازی می‌کنند و درک درستی از کاربرد آن در سازمان بطور تجربی ندارند.

مدانت دوره‌های آموزشی ITIL را در سطح کشور ارایه داده اما فقط به این مهم بسنده نکرده، در کنار آموزش، شیوه‌ی پیاده‌سازی آن با یک ابزار محبوب Manageengine ServiceDesk Plus و کلیدی بصورت عملیاتی، گام بسیار مهمی در کاربردی کردن چارچوب ITIL برداشته است.

هادی احمدی

نوشته ITIL نظری یا کاربردی؟ اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

هوش مصنوعی در خدمت مدیریت خدمات

مغز جدید ChatGPT اگرچه غوغایی به پا کرده اما این چیز بدیع و عجیبی نیست و مدت‌هاست که متخصصان روی هوش مصنوعی فعالیت دارند تا بتواند جایگزین بسیاری از کارهای تکراری باشد، آنچنان که سریع بگردد و بهترین پاسخ را بیابد و به زبان انسان بیان کند. از دستیار صوتی Siri شرکت اپل گرفته تا Cortana شرکت مایکروسافت. حتی می‌بینیم اکثر موتورهای جستجو و بسیاری از ابزارهای پزشکی، تشخیص چهره، پلاک و … به هوش مصنوعی مجهزند.

این مغز مبتنی بر هوش مصنوعی یا AI، توسط متخصصان فناوری اطلاعات و ارتباطات عرضه شده اما بیشتر اوقات خود فناوری اطلاعات از دستاوردهایش بی‌نصیب است و با این‌که خودش خالق و مبتدع تکنولوژی است اما دیگران و صنایع دیگر، بیشتر از آن استفاده می‌کنند. بعبارتی فناوری اطلاعات شبیه کوزه‌گر می‌شود که از کوزه شکسته آب می‌خورد. امروزه این هوش مصنوعی از آزمایشگاه‌ها به سمت مردم سرازیر شده. در تلفن همراه یا برای نوشتن یک مقاله و …

پس ضروری است خود فناوری اطلاعات نیز بی‌نصیب از آن نباشد. هوش مصنوعی در سیستم‌های مدیریت خدمت و چارچوب ITIL می‌تواند به شدت نقش مهمی ایفا کند. بهمین خاطر شرکت ManageEngine‌ با تکنسین‌ربات Zia به بهره‌گیری از AI رفت.

چطور؟ همچنان که در ChatGPT یک مغز مصنوعی می‌تواند  ۱۰ برابر سریعتر بنویسد، در فناوری اطلاعات نیز یک مغز مصنوعی می‌تواند ۱۰ برابر سریعتر به کاربران پاسخ دهد. بعبارتی سرعت پاسخ و رفع مشکل و پیگیری درخواست‌های آنان اکنون توسط ربات‌تکنسین‌ها بخوبی قابل ارایه است. بعبارتی کاربرد هوش مصنوعی در ITIL می‌تواند زنگ خطری برای تمام کارشناسان فناوری اطلاعات باشد که این مغز مصنوعی می‌تواند جای همه‌شان را بگیرد!…

هوش مصنوعی، چت‌بات[۱]، گزارشات تحلیلی و ادغام‌پذیری بهتر و آسان‌تر مهمترین ویژگی و قابلیت‌های جدید نرم‌افزارهای اتوماسیون سازمانی بخصوص ابزارهای پیاده‌سازی ITIL در آینده‌ی نزدیک خواهد بود، اگرچه برخی از ارایه‌دهندگان کم و بیش این ویژ‌گی‌ها قدرتمند را در نرم‌افزار گنجانده اند نظیر چت‌بات Zia شرکت Managenegine اما حسب نوپا بودن هوش‌مصنوعی به‌نظر هنوز در ابتدای راه است.

هوش مصنوعی:

هوش مصنوعی به کمک ITIL خواهد آمد تا درک بهتر و درست‌تری از وقایع، حوادث و کارها داشته باشد تا در صورت لزوم با ایجاد و یا ردیابی حوادث پیش از وقوع مشکلات فراگیر و گسترده، تمهیدات لازم را جهت به حداقل‌رساندن نرخ خرابی‌ها و تأثیر آنها بر کسب و کار سازمان به اجرا بگذارد شکی نیست که اغلب تمرینات ITIL رفته‌رفته از حیث وابستگی به درج اطلاعات و مستندسازی توسط کارکنان فناوری از طریق بکارگیری هوش مصنوعی بی‌نیاز خواهد شد و این خبری خوبی است تا سهم عمده‌ای از نرخ خطاهای انسانی کاهش یابد و راندمان ارایه‌ی خدمات سازمانی به حداکثر حالت برسد.

چت‌بات‌ها:

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

گزارشات هوشمند:

 قطعا هر ابزاری مجهز به یک داشبورد مدیریتی از گزارشات سفارشی هست اما لزوما هوشمندسازی آنها بر پایه‌ی تحلیل و نه صرفا دریافت آمار عددی چیزی است که در ابزارهای ITIL گنجانده خواهد شد زیرا لازم است مدیران گزارشگیر و تحلیل‌گران و داده‌کاوان اطلاعات مناسب‌تری دریافت کنند تا قدرت تصمیم‌گیری آنها افزایش یابد و صرفا با اعداد و ارقام سیستمی  و کمی بدون لحاظ کردن ارزش‌ها و کیفیت کار در چاه مشکلات سقوط نکنند. گزارشات هوشمند هم هوش مصنوعی را طلب خواهد کرد و در آینده‌ی نچندان دور مدیران فناوری اطلاعات با نگاهی وسیع‌تر می‌توانند تصویر بزرگ [۲]و برنامه‌های بلندمدت خود را در حوزه‌ی ICT پیش ببرند.

یکپارچه‌سازی آسان:

در پایان ادغام‌سازی و یکپارچگی هوشمندتر و آسان‌تر با سایر سرویس‌های سازمانی مهمترین تغییر در ابزارهای ITSM خواهد بود. در مطالب پیشین درباره ERP شکست‌خورده سخنی در این خصوص رانده‌ام و اینکه دیگر مثل سابق سازمان‌ها به‌دنبال یک نرم‌افزار غول‌پیکر نیستند که تمامی کارها را انجام دهد زیرا هر باید یقین داشت که هرکسی را بهر کاری ساخته‌اند قطعا یک نرم افزار در حوزه ی برنامه‌ریزی شیفت ورود و خروج پرسنل با گرافیک خاص! نظیر: Employee Shift Scheduling Software را نمی‌توان با ERP به آن شکل حرفه‌ای پیاده کرد و یا یک نرم‌افزار چاپ لیبل نظیر LableJoy. بنابراین سازمان‌ها دنبال ابزارهایی هستند تا از قابلیت OpenAPI پشتیبانی کند آنچنان که تمامی ابزارها بتواند با هر قابلیت منحصری که دارد با همدیگر صحبت کنند. اما فقط موضوع صحبت‌کردن نرم‌افزارها باید یکدیگر جهت کاهش حجم ورود اطلاعات نیست بلکه باید روش یکپارچه‌سازی آنها نیز تسهیل شود بنابراین این وسط نرم افزارهای واسط و یا API های ارتقا یافته‌ی هوشمند عرضه خواهد شد تا در کمترین زمان و با حداقل کدنویسی بتوان از داده‌‌های یک نرم‌افزار در جایی دیگر استفاده و اطلاعات را بین حجم زیادی از ابزارهای دیگر سازمان رد و بدل کرد.

   لزوم کاهش کارکنان خط پشتیبانی، بکارگیری آنها در پروژه‌هایی که منجر به خلق ارزش مثبت می‌شود و همچنین کاهش هزینه‌ها و البته افزایش راندمان ابزارها در خدمت سازمان همه و همه بصورت هوشمند، مهمترین اهداف هر سازمانی است و تردیدی نیست که این نیازمندی‌ها به‌شدت احساس می‌شود و در آینده‌ای بسیار نزدیک ساده بکارگیری قابلیت‌ هوش مصنوعی بطور گسترده در نرم‌افزارهای پیاده‌سازی ITIL خواهیم بود.

نازنین رادمهر

[۱] از چت‌بات جهت شبیه‌سازی مکالمات هوشمند با یک یا چند کاربر انسانی از طریق صدا یا متن استفاده می‌شود نظیر بات‌های تلگرام! نام دیگر آن بات مکالمه دستیار مجازی هوشمند (Intelligent Virtual Assistant) می باشد.

[۲] Big Picture

نوشته هوش مصنوعی در خدمت مدیریت خدمات اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.