مقایسه Servicedesk Jira و ManageEngine Servicedesk Plus کدام یک برای نیازهای تجاری شما بهتر است؟

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

همانطور که کسب و کارها رشد می‌کنند، زیرساخت‌ها و پیچیدگی‌های فناوری اطلاعات آنها نیز افزایش می‌یابد. با این امر نیاز به یک میز خدمت برای مدیریت عملیات روزانه IT وجود دارد. میز خدمت بخشی ضروری از زیرساخت فناوری اطلاعات یک سازمان است. این یک نقطه تماس برای کاربران است تا مشکلات را گزارش کنند، خدمات درخواست کنند و کمک بخواهند. همچنین بستری را برای تیم‌های فناوری اطلاعات برای مدیریت و حل این مسائل فراهم می‌کند. در این مقاله، دو ابزار محبوب ، Servicedesk Jira  و ManageEngine Servicedesk Plus را با هم مقایسه می‌کنیم تا به شما در انتخاب بهترین مناسب برای نیازهای کسب‌وکارتان کمک کنیم.

میز خدمت چیست؟

قبل از اینکه به مقایسه بین Servicedesk Jira و ManageEngine Servicedesk Plus بپردازیم، اجازه دهید ابتدا تعریف کنیم که میز خدمت چیست. میز خدمت، عملکردی در بخش فناوری اطلاعات سازمان است که مسئول مدیریت حوادث، درخواست‌های خدمات و تغییرات است. این یک نقطه تماس برای کاربران برای گزارش مشکلات، درخواست خدمات و جستجوی کمک است. میز خدمت بخشی ضروری از زیرساخت فناوری اطلاعات سازمان است زیرا به اطمینان از ارائه کارآمد و مؤثر خدمات فناوری اطلاعات کمک می‌کند.

اهمیت داشتن ابزار ITIL

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

مروری بر Servicedesk Jira و ManageEngine Servicedesk Plus

Servicedesk Jira و ManageEngine Servicedesk Plus دو مورد از محبوب‌ترین ابزارهای ITIL هستند که توسط سازمان‌ها در سراسر جهان مورد استفاده قرار می‌گیرند. Servicedesk Jira یک نرم افزار میز خدمت است که توسط Atlassian توسعه یافته است، در حالی که ManageEngine Servicedesk Plus یک نرم افزار میز خدمت است که توسط ManageEngine، بخشی از Zoho Corporation توسعه یافته است.

ویژگی‌های کلیدی Servicedesk Jira

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

گردش کار قابل تنظیم

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

همکاری

Servicedesk Jira  بستری را برای همکاری بین تیم‌های فناوری اطلاعات و سایر بخش‌های درون سازمان فراهم می‌کند. این به تیم‌ها اجازه می‌دهد تا روی مسائل و درخواست‌های خدمات با هم کار کنند و اطمینان حاصل شود که خدمات فناوری اطلاعات به طور کارآمد و مؤثر ارائه می‌شوند.

اتوماسیون

Servicedesk Jira  ویژگی‌های اتوماسیونی را ارائه می‌دهد که به تیم‌های فناوری اطلاعات کمک می‌کند تا فرآیندهای مدیریت خدمات فناوری اطلاعات خود را ساده کنند. این کار کارهای روتین مانند تخصیص تیکت، به روز رسانی وضعیت و اعلان‌ها را خودکار می‌کند.

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

نوشته <strong>مقایسه Servicedesk Jira و ManageEngine Servicedesk Plus کدام یک برای نیازهای تجاری شما بهتر است؟</strong> اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

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

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

۱- وقتی تعمیر و نگهداری زیادی موردنیاز است.

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

 ۲- وقتی پرسش و پاسخ‌ها در حال تکرارند.

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

۳ – وقتی آتش‌نشان هست اما آتش‌سوزی واقعی وجود ندارد!

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

۴ – وقتی راه‌حل مدیریت خدمات فعلی با نیاز سازمان شما سازگار نیست.

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

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

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

چالش‌های تماس تلفنی بر میزخدمت

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

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

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

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

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

از نظر کاربر، تماس تلفنی ساده‌تر او را به پاسخ می‌رساند و سریع‌تر نسبت به دریافت خدمت نایل خواهد شد. این چیز بدی نیست رضایتمندی، سرعت و ارایه‌ی خدمت به‌موقع جزو ارکان ITIL است. اما چرا ابزارهای پیاده‌سازی ITIL سعی دارند نرخ تماس تلفنی را کاهش و حتی کاملاً حذف کنند؟

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

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

مشکلات تماس تلفنی:

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

یک نفر را بگذارید که به درخواست‌ها فوراً پاسخ دهد ارزشمندتر از این است که یک منشی تلفنی داشته باشید!

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

با ابزار پیاده‌سازی ITIL‌ بیش از ۶۵٪ مکالمات تلفنی از بین می‌رود و این یک نقطه‌ی هدف ارزشمند و سودآور است!

هادی احمدی

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

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

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

مشکل کجاست؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

هادی احمدی

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

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

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

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

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

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

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

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

مبانی ITIL چیست؟

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

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

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

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

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

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

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

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

پورتال سلف سرویس چیست، کاربرد و مزایای آن کدامند؟

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

به عبارتی ساده تر: پورتال خودخدمتی یا Self Service Portal یک درگاه از نرم افزار هلپ دسک یا سرویس دسک است که شامل قابلیتهایی برای خودآموزی و خودخدمتی است که کاربر را قادر می سازد تا درخواست های خرابی یا خدمات خود را ثبت، پیگیری و بازبینی کند، همچنین قادر به مشاهده اطلاعیه ها، زمان حل و فصل درخواست ها، راهکارها، اطلاعات و راه حل های مسائل، نحوه پیگیری وضعیت درخواست ها و.. نیز هست. بسیاری از ابزارهای پیاده سازی ITIL  دارای یک پورتال خودخدمتی هستند.

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

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

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

چرا پورتال سلف سرویس ضرورت دارد؟

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

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

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

آمارهای ضرورت پورتال سلف سرویس از نگاه مصرف کننده

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

طراحی پورتال سلف سرویس

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

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

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

موضوع: “بازنشانی رمز عبور”

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

نوشته پورتال سلف سرویس چیست، کاربرد و مزایای آن کدامند؟ اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.