MedaNet Journal

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

از ITSM و ITIL تا دارایی، عملیات، امنیت، هویت و محصولات ManageEngine؛ موضوع را پیدا کنید، سناریو را بخوانید و به اجرا برسید.

مسیرهای مطالعه

بر اساس مسئله بخوانید، نه فقط بر اساس تاریخ

تازه‌های مدانت

جدیدترین مقالات

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

KEEP LEARNING

موضوعی در ذهن دارید؟ از جست‌وجوی مدانت شروع کنید

میان صدها مقاله، راهنما، محصول و صفحه تخصصی، سریع‌تر به پاسخ مناسب برسید.

جست‌وجو در کل مدانت
مهر ۱۱, ۱۴۰۳

پیشنهاد نگار چالاک!

پیشنهاد نگار چالاک! #نگار_چالاک، مدیر خلاق و پرانرژی تیم توسعه نرم‌افزار در شرکت #آرمان‌‌_خواه_پرتلاش، به‌تازگی متوجه شد که یکی از قابلیت‌های قدیمی برنامه، یعنی امکان چاپ اطلاعات سازمان دیگر مورد استفاده کاربران قرار نمی‌گیرد.پیشنهاد جایگزینی این قابلیت مطرح شد و قرار شد جایش را به یک ویژگی جدید و کارآمدتر بدهد: ارسال اطلاعات از طریق ایمیل بجای چاپاو می‌دانست که تغییر در نرم‌افزار فقط نیمی از کار است اما این تغییر را ضروری و فوری می‌دید. #یلدا_دانا که مدیر دانش بود، وقتی این را شنید جا خورد. او به اهمیت همکاری و به‌اشتراک‌گذاری اطلاعات میان تیم‌ها باور داشت.می‌گفت: «دانش فقط انباشت اطلاعات نیست؛ بلکه باید فضایی ایجاد کنیم که همکاران به‌راحتی تجربیات، مشکلات و راه‌حل‌های خود را با یکدیگر به اشتراک بگذارند. این تنها راهی است که می‌توانیم با چالش‌های جدید روبه‌رو شویم.» پس گفت باید ابتدا مستند آموزشی را به اشتراک گذاشت تا بازخورد کاربران را دریافت کنیم تا کاربران بدون دردسر از ویژگی‌ جدید بهره‌مند شوند. اما #امین_ایمن، مدیر فناوری اطلاعات، نگران بود. او همیشه تأکید می‌کرد که در دنیای دیجیتال امروزی، امنیت اطلاعات حیاتی است.می‌گفت: «باید دقت کنیم که این قابلیت سبب اشتراک‌گذاری آزاد اطلاعات سازمانی و منجر به بی‌احتیاطی نشود.» او همراه با تیم امنیت، رویه‌هایی سخت‌گیرانه‌ای را همواره طراحی می‌کرد که حتی گاهی جلوی تغییرات و نوآوری‌ها را می‌گرفت. و آقای #حامی_تنها مدیر پشتیبانی کاربران زد زیر میز که این تغییر، کلی درخواست ناخواسته روانه‌ پشتیبانی می‌کند و ترافیک بیخود ایجاد میشود.—هرکسی سازی می‌زد و به نظر تغییر پیشنهادی نگار، راه دشواری داشت تا این‌که، #کمال_پرمغزیان، یکی از نوآوران جوان در شرکت، دیدگاه تازه‌ای به شرکت آورد. او که علاقه‌مند به تکنولوژی‌های پیشرفته بود، به تیم پیشنهاد کرد از سیستم‌های هوش مصنوعی برای بهبود فرآیندهای تصمیم‌گیری و پیش‌بینی استفاده کنند.با شور و شوق توضیح داد: «این سیستم‌ها می‌توانند نه‌تنها در سطح استراتژیک، بلکه حتی در پشتیبانی از کاربران و پیش‌بینی نیازهای آنها به ما کمک کنند.» ایده‌هایش توانست مسیر تازه‌ای برای رشد و بهبود در شرکت باز کند.—چندی نگذشت که شرکت با تلفیق #مدیریت_تغییر و #مدیریت_دانش #مدیریت_امنیت_اطلاعات در کنار تکنولوژی‌های پیشرفته AI توانست هم تغییرات مد نظر نگار چالاک را به بهترین وجه به سرانجام برساند هم یلدا دانا جا نخورد و هم امین ایمن از نشت اطلاعات نگران نباشد و هم چت‌بات‌های هوش مصنوعی به کمک حامی تنها آمدند.آنها با استفاده از سیستم‌های هوشمند، توانستند نه تنها خدمات بهتری به کاربران خود ارائه دهند، بلکه در بازار به‌سرعت رشد کرده و رهبری خود را تثبیت کنند.www.MedaNet.ir
مهر ۱۰, ۱۴۰۳

سیستم ارزش خدمات (Service Value System – SVS) در ITIL 4

سیستم ارزش خدمات (Service Value System – SVS) در ITIL 4 سیستم ارزش خدمات (SVS) قلب چارچوب ITIL4 است و به عنوان یک مدل جامع برای مدیریت خدمات IT در نظر گرفته می‌شود. هدف SVS این است که سازمان‌ها بتوانند از طریق مدیریت مؤثر فرآیندها، منابع و قابلیت‌ها، ارزش واقعی را به مشتریان و کسب‌وکار ارائه دهند. در ITIL 4، SVS شامل تمام اجزایی است که برای مدیریت مؤثر خدمات IT و تولید ارزش به کار گرفته می‌شوند. این سیستم به طور کلی حول چند عنصر کلیدی شکل گرفته که به کمک آنها خدمات بهبود می‌یابند و ارزش‌آفرینی تسهیل می‌شود. سیستم ارزش خدمات (SVS) در ITIL 4 به عنوان یک چارچوب جامع برای مدیریت خدمات IT عمل می‌کند. این سیستم از طریق اجزای کلیدی مانند اصول راهنما، زنجیره ارزش خدمات، حاکمیت و بهبود مداوم به سازمان‌ها کمک می‌کند تا با هم‌راستایی خدمات IT و استراتژی‌های کسب‌وکار، ارزش بیشتری برای مشتریان و خود سازمان ایجاد کنند. برای پیاده‌سازی موفق SVS، باید از اصول راهنمای ITIL شروع کرده، سپس با تمرکز بر زنجیره ارزش خدمات و حاکمیت، گام‌به‌گام به سمت بهبود مداوم پیش بروید. برای هر یک از بخش‌های زنجیره ارزش خدمات (Service Value Chain) در ITIL 4، یک مثال عملی در نظر می‌گیریم تا نشان دهیم این فعالیت‌ها چگونه در عمل پیاده‌سازی می‌شوند. ادامه‌ی مطلب در صفحه بعد…
مهر ۱۰, ۱۴۰۳

SLA چیست؟

SLA (Service Level Agreement) یا توافق‌نامه سطح خدمات، سندی رسمی میان ارائه‌دهنده و دریافت‌کننده خدمت است که انتظارات، مسئولیت‌ها و شاخص‌های قابل‌اندازه‌گیری سرویس را مشخص می‌کند. معیارهایی مانند زمان پاسخ، زمان رفع، دسترس‌پذیری، ساعات پشتیبانی و نحوه Escalation معمولاً در SLA تعریف می‌شوند. هدف SLA ایجاد شفافیت و جلوگیری از برداشت‌های متفاوت درباره کیفیت خدمت است. برای اینکه SLA قابل اجرا باشد، باید شاخص‌ها قابل‌اندازه‌گیری، مسئولیت طرفین روشن و روش گزارش‌گیری مشخص باشد. در کنار SLA، دو مفهوم مرتبط هم مهم‌اند: SLO که هدف کمی سطح خدمت را مشخص می‌کند و OLA که تعهد میان تیم‌های داخلی برای تحقق SLA را تعریف می‌کند. برای اجرای این مدل در محیط عملیاتی، استفاده از ServiceDesk Plus می‌تواند ثبت، اندازه‌گیری و گزارش SLA را ساختاریافته کند.
مهر ۱۰, ۱۴۰۳

Known Error چیست؟

Known Error یا «خطای شناخته‌شده» در ITIL به Problemی گفته می‌شود که تحلیل شده، اما هنوز به‌طور کامل برطرف نشده است. ممکن است برای آن Workaround وجود داشته باشد، اما وجود Workaround شرط تعریف Known Error نیست. Known Error چه زمانی ایجاد می‌شود؟ وقتی تیم Problem Management علت، الگو یا شرایط یک مشکل را به اندازه کافی تحلیل کرده باشد و بتواند اطلاعات مفیدی برای تیم‌های پشتیبانی ثبت کند، آن Problem می‌تواند به‌عنوان Known Error مدیریت شود؛ حتی اگر Permanent Fix هنوز آماده نباشد. تفاوت Known Error و Workaround مفهوم تعریف Known Error Problem تحلیل‌شده‌ای که هنوز حل نهایی نشده است Workaround راهی برای کاهش یا حذف موقت اثر Incident یا Problem بدون حل علت اصلی یک مثال ساده فرض کنید یک سرویس هر بار پس از افزایش بار دچار قطع ارتباط می‌شود. تیم فنی متوجه می‌شود علت به Memory Leak در یک Component مربوط است، اما Patch نهایی هنوز آماده نشده. Restart دوره‌ای سرویس می‌تواند Workaround باشد و خود Problem نیز به‌عنوان Known Error ثبت شود تا Service Desk در رخدادهای بعدی سریع‌تر عمل کند. برای درک بهتر ارتباط Incident، Problem و Root Cause Analysis، مقاله RCA چیست؟ را هم ببینید.
مهر ۱۰, ۱۴۰۳

SVS چیست؟

SVS مخفف Service Value System یا «سیستم ارزش خدمات» است؛ مدلی در ITIL 4 که نشان می‌دهد اجزای مختلف سازمان چگونه باید کنار هم کار کنند تا از تقاضا و فرصت، ارزش برای مشتری، کاربر و خود سازمان ساخته شود. SVS فقط یک فرایند یا دیاگرام نیست. این مدل یک نگاه کل‌نگر به مدیریت خدمات است و حاکمیت، اصول راهنما، زنجیره ارزش خدمات، Practices و بهبود مستمر را در یک سیستم واحد کنار هم قرار می‌دهد. اجزای اصلی SVS در ITIL 4 Guiding Principles: اصول راهنما برای تصمیم‌گیری و بهبود. Governance: هدایت، ارزیابی و نظارت سازمان. Service Value Chain: فعالیت‌هایی که تقاضا و فرصت را به ارزش تبدیل می‌کنند. Practices: قابلیت‌ها و روش‌های لازم برای مدیریت خدمات. Continual Improvement: بهبود مستمر در تمام اجزای سیستم. برای بررسی دقیق‌تر این پنج جزء، مقاله ساختار و اجزای SVS در ITIL 4 را ببینید. تفاوت SVS با Service Value Chain چیست؟ SVS کل سیستم مدیریت ارزش است؛ اما Service Value Chain فقط یکی از اجزای آن است. زنجیره ارزش خدمات فعالیت‌های Plan، Improve، Engage، Design & Transition، Obtain/Build و Deliver & Support را به هم متصل می‌کند. Value Stream نیز مسیر مشخصی از همین فعالیت‌ها برای تحقق یک نتیجه واقعی است. برای درک این بخش، Value Stream در ITIL 4 را مطالعه کنید. یک مثال ساده از SVS فرض کنید کاربران از کندی یک سرویس سازمانی شکایت دارند. در نگاه SVS فقط تیم فنی مسئول نیست. نیاز کاربر باید دریافت شود، اولویت کسب‌وکار مشخص شود، تغییرات لازم تحت حاکمیت انجام شوند، تیم‌های مختلف هماهنگ شوند و نتیجه نهایی اندازه‌گیری شود. اگر این چرخه به بهبود واقعی تجربه کاربر منجر شود، سازمان از اجزای SVS برای خلق ارزش استفاده کرده است. چرا SVS مهم است؟ از مدیریت جزیره‌ای فرایندها جلوگیری می‌کند. IT را به اهداف و اولویت‌های کسب‌وکار متصل می‌کند. به سازمان کمک می‌کند خروجی فنی را با ارزش واقعی اشتباه نگیرد. حاکمیت، اجرا و بهبود را در یک مدل یکپارچه قرار می‌دهد. برای مرور اصطلاحات مرتبط نیز واژه‌نامه ITIL 4 و برای درک عمیق‌تر مفهوم ارزش، مقاله قلب ITIL 4 و مفهوم ارزش مفید است. سخن پایانی SVS یادآوری می‌کند که مدیریت خدمات فقط اجرای چند فرایند نیست؛ همه اجزای سازمان باید در یک سیستم هماهنگ کار کنند تا نتیجه‌ای ایجاد شود که واقعاً برای ذی‌نفعان ارزش داشته باشد.