حجم بالایی از بودجه سازمان ها، صرف فناوری اطلاعات می شود که برای ایجاد ارزش تجاری و پشتیبانی از رشد اقتصادی سازمان است. و واحد ITبخش بزرگی از این بودجه را به خود اختصاص می دهد اما بسیاری از فناوری اطلاعات سازمان ها بخش زیادی از این بودجه را فقط برای مدیریت حوادث صرف می کنند. میز خدمات امروزی در جای جای مراکز شناخته شده از: وجود تعداد زیادی از افراد برا پشتیبانی، ابزارهای مدیریت تلفن و تلفن های گران قیمت، چارت و سلسه مراتب های سازمانی برای مدیریت حادثه و… تشکیل شده. پشتیبانی لایه ۱، لایه ۲ و حتی بیشتر… سبب استخدام نیروهای افراد گران قیمت و صرف هزینه های نگه داشتن نیروهای باتجربه می شود به انضمام اینکه قراردادهای پشتیبانی پیمانکاران و ارایه کنندگان برخی تجهیزات و یا سرویس های برون سپاری شده نیز می تواند گران باشد. تصور کنید داریم به کجا می رویم با این آشفته بازار!
در عوض، فناوری اطلاعات با این سرمایه گذاری! برای مشتریان خود چه می کنند؟ در بهترین حالت، آنها می توانند از کاهش و سقوط ناگهانی کسب و کار به دلیل ناکامی خدمات جلوگیری کنند. بنابراین در این حالت، هرگز نخواهید توانست به مشتریان خود بگویید: “ما یک کار خارق العاده انجام دادیم که حوادث را مدیریت کردیم!” چون شما هیچ کاری برای رشد کسب و کار انجام نداده اید! زیرا مشتریان از شما انتظار دارند که حوادث را حل کنند؛ و بجز تامین این انتظارات، شما، هیچ ارزش افزوده ای برای آنها یا فرآیندهای کسب و کار ایجاد نکرده اید.
فراموش نکنید ارایه خدمات در حد مطلوب، جزو پیش فرض های شما در جهت تامین انتظارات مشتری است بنابراین ارایه این انتظارات را در بوق و کرنا نکنید و به مشتری مرتبا یادآور شوید!
فرض کنید که شما ۵۰۰ (رخداد) را در این ماه مدیریت کردید – هر یک از آنها به طور کامل مدیریت شده و شما تمام اهداف SLA سازمان را برای زمان حل و فصل رعایت کرده اید همچنین پس از انجام کار طبق SLA، یک نظرسنجی نیز ترتیب داده اید که نظر مشتری در مورد عملکرد شما در مواجه شدن با حوادث را نشان می دهد و قطعا نمودار نتایج نظرسنجی، نشانگر رضایت کاربران از مدیریت حوادثی که ارائه شده، است. بنابراین ظاهرا آنها راضی هستند!
اما به نظر شما اگر به مشتری یا کاربر نهایی بگویید که: “اگر ماه آینده ما ۱۰۰۰ حادثه را مدیریت کنیم، آیا این موضوع شما را خیلی خوشحال تر کند!؟” صد البته پاسخ منفی خواهید گرفت و آنها می گویند: اصلا چرا سرویس خوب و پایداری ارایه نمی دهید تا مجبور به تعمیرات روزانه نباشید!”
چرا آنها خوشحال نمی شوند!؟ شما که در لحظه درخواست های حوادث را رفع رجوع کرده اید پس چرا اگر تعداد این رفع رجوع ها بیشتر شود خوشحالی آنها بیشتر نمی شود!؟
پاسخ خیلی ساده است: به این دلیل که مدیریت حوادث، هیچگونه ارزشی برای مشتری و کسب و کار، ایجاد نمی کند و در عین حال به سادگی، افزایش نرخ خرابی ها، مقدار ارزش کسب و کار فعلی سازمان شما را هم کاهش می دهد.
مشتریان شما، زمانی واقعا خوشحال هستند که هرگز حوادثی نداشته باشند.
شاید بپرسید پس چرا همکنون آنها اعلام رضایت کرده اند!؟ زمانی که اتفاقی رخ می دهد، آنها مطمئنا شما را آرام می کنند تا به سرعت حوادث را مرتفع کنید پس ممکن است در آن حال در تمام طول نظرسنجی، همواره نظر مثبتی ارایه کنند در حالیکه این نظر از سر ناچاری و صرفا برای اطمینان بخشی به شماست!
واقعیت این است که صرف نظر از اینکه مدیریت حادثه چقدر خوب است، اما مدیریت حادثه هرگز سبب ایجاد ارزش برای کسب و کار نخواهد شد.
بخش بزرگی از بودجه سازمان ها در کلیه بخش های ارایه کننده خدمات نظیر: فناوری اطلاعات، صرف فعالیت هایی می شود که هیچ گونه ارزش تجاری را ایجاد نمی کند، اگرچه همین ارایه خدمات را نیز اگر متوقف کنیم سبب نارضایتی بیشتر مشتریان می شود، پس چه باید کرد؟ چگونه می توانیم از این طریق مدیریت کنیم؟ راه حل واضح، این است: سرمایه گذاری در کاهش تعداد حوادث و کاهش اختلال کسب و کار ناشی از حوادثی که ما نمی توانیم جلوگیری کنیم. به این ترتیب ما می توانیم با افزایش توانایی IT برای پاسخگویی به نیازهای سازمان، پاسخ صحیح و سریع بدهیم و رضایت مشتری را افزایش دهیم و در عین حال یک ارزش مثبت هم ایجاد کنیم. اگر ما کار خوبی انجام دهیم، ممکن است متوجه شویم که می توانیم بودجه مان را از مدیریت حوادث به سمت چیزهایی که به رشد کسب و کار کمک می کنند، مجددا اختصاص دهیم.
من زمان زیادی را صرف فکر کردن درباره چیزهایی کردم که می توانیم برای کاهش میزان مدیریت حوادثی که انجام می دهیم، انجام دهیم، و تعداد زیادی از آنها وجود دارد، اما اغلب بخش های فناوری اطلاعات تقریبا به همان اندازه در این موارد سرمایه گذاری نمی کنند؛ و دائماً تمرکزشان تنها انجام و مدیریت حوادث است. در اینجا برخی از زمینه هایی وجود دارد که من فکر می کنم بخش های IT باید سرمایه گذاری کنند. اما متاسفانه و بدبختانه نه پرسنل و نه مدیران فناوری به این مهم تمرکز ندارند! زندگی روزمره ی کاری و پاسخ دادن به چند تلفن و ایمیل و بستن درخواست های جاری و رفع ارباب الرجوع تمام ذهنیت نیروهای ارایه کننده خدمت شده است. علاوه بر آسیب هایی نظیر کاهش انگیزه های شغلی و… این مقوله آسیب جدی به آینده کاری و عملکرد فناوری اطلاعات در میان مدت می شود.
یکی از مهمترین علل این کم کاری ناشی از کارشناسان فناوری اطلاعات است آنها انتظار دارند در ازای حجم حوادثی که رفع رجوع می کنند باید پاداش و ترفیع بگیرند در حالیکه با توجه به بند نخست این بحث:
تا زمانی که برای سازمان، خلق ارزش نکنید انتظاری برای بهبود پاداش و ارتقای شغلی نیز نداشته باشید!
خیلی ها در جلسات آموزشی و یا در نظرات شخصی خود به من گفته اند که من کاملاً جانبدارانه و فقط به نفع سازمان سخن می گویم و مدام دم از تلاش بیشتر کارشناسان ارایه خدمت می کنم و خبری از روش های دریافت پاداش و… نیست!
برعکس من هرگز طرفدار نظام سرمایه داری و رئیس مرئوسی نبوده و نیستم، اما دوستان، طلب پاداش در ازای خدمتی که جزو انتظارات و پیش فرض های شغلی ماست ارزش نیست شما تازمانیکه نگاه مدیریتی به شغل، زمان و توانایی خود نداشته باشید هرگز مسیر پیشرفت را طی نخواهید کرد برعکس من مقالات بسیاری راجب کم توجهی مدیران هم نوشته ام اما همیشه این نکته را بخاطر داشته باشید
شما باید برای مدیران تصمیم بسازید تا آنها بتوانند تصمیم بگیرند!
جدای از تجربه، سواد، شایستگی و… مدیران فناوری اطلاعات، شما به عنوان کارشناس در حیطه کاری خود باید بهترین باشید و شک نکنید جای بهترین ها در بهترین جاها خواهد بود.
مدیریت مشکل دارای دو جنبه است و هر دوی آنها برای کمک به کاهش فرکانس تکرار و تاثیر حوادث بر روی کسب و کار، مهم هستند.
دلایل زیادی دارد که بسیاری از فناوری اطلاعات سازمان ها کمتر سراغ مدیریت مشکل می روند. شایع ترین فعالیت مدیریت مشکلی که من در اغلب سازمان های می بینم، تجزیه و تحلیل ریشه ای حوادث است که پس از حوادث عمده انجام می شود تا سعی شود از تکرار آنها جلوگیری شود. این مهم است، اما تنها بخش کوچکی از مدیریت مشکل است.
من به طور منظم از همه فقط این را می شنوم که می گویند:”نمی توانیم مدیریت مشکل بیشتر را انجام دهیم، چون بیش از حد مشغول هستیم!” بارها شده در جلسات آموزش ITSM حتی افراد از ترس زیر سوال رفتن و یا برای یک تماس بی پاسخ گذاشتن کاربران نگران بودند و در جلسه های آموزشی حضور نمی رساندند همواره یک نگرانی مستمر از اینکه همین الان ممکن است یک جایی آتش بگیرد! داشتند. دقیقا فناوری اطلاعات شبیه آتش نشانی شده! و این آتش نشان ها همیشه در لحظه حادثه، جان فدایی می کنند و در لحظاتی که خبری از آتش نیست آماده باش و بدون هیچ ابتکاری در انتظار آتش سوزی دیگری هستند. به طور معمول علت این نوع واکنش منفعلانه به این دلیل است که آنها حوادث بسیار زیادی دارند که نمیتوانند افراد را برای جلوگیری از وقایع در اولویت قرار دهند. اگر فقط آنها می توانستند به مدت کوتاهی مکث کنند و از حوادث عقب نشینی کنند، ممکن است بتوانند این چرخه بد و نامتقارن سخت را کنار بگذارند. تصویر زیر گویای تمام این حرف من است. انجام یک کار در مدیریت یک مشکل کوچک هم می تواند به کاهش اندکی در نرخ حوادث منجر شود، پس با آزاد سازی منابع حتی به اندازه یک نفر/دقیقه می توان در انجام کارها، مدیریت مشکلات بیشتری را هندل کنیم. اگر کارکنان پشتیبانی شما ۵ نفر باشند و هر کدام فقط ۵ دقیقه وقت، آزاد کنند در روز می شود تا حدود نیم ساعت به بررسی یکی از پر تکرارترین حوادث پرداخت و راهکارهای کاهش و رفع موقت یا ریشه ای آنرا تدارک دید! به همین راحتی! گاهی ممکن است باتوجه به برخی مسائل، این موقعیتی را ممکن است برای مدت کوتاهی به یک پیمانکار بسپارید تا با داده کاوی، نتایج کاهش حوادث را برای شما ترسیم کند، کارگروه مهندسی شرکت مدانت در سایت “حل مشکل با ITSM به ارمغان بیاورد، برای اینکه مدیریت مشکل را آغاز کند و افرادی را که پس از آن می توانند فرآیند را به دست بگیرند آزاد می کنند.
یکی از رویکردهایی که من برای مدیریت مشکل ایجاد کرده ام، این است که هر ماه یک گزارش مشکل “Top 5” ایجاد کنم و این پنج مشکل را مدیریت کنم. این گزارش بر اساس تجزیه و تحلیل روند حوادث است و به سادگی پنج مسئله را که بیشترین تأثیر منفی را بر کسب و کار در هر ماه داشته اند، شناسایی می کند. سپس کارکنان مدیریت مشکل با کاهش تاثیر این مشکلات (با تایید راه حل ها) یا فرکانس(نرخ تکرار) آنها کار می کنند. اثربخشی این رویکرد را می توان با گزارش از تاثیر کلی تجاری این پنج مشکل در ماه های متوالی پس از اولین بار شناسایی کرد.
چندین چیز ساده دیگر وجود دارد که سازمان های فناوری اطلاعات می توانند برای بهبود مدیریت مشکل خود اقدام کنند، مثلا:
تمرکز مدیریت مشکل را از تحلیل علل ریشه ای دور کنید. یعنی تمام تمرکز خود را در مدیریت مشکل، فقط بر روی مستندسازی علل مشکل نکنید! مهم است که مشکل را شناسایی و راه حل هایی برای جلوگیری از تکرار حوادث بکار گیریم. تجزیه و تحلیل علت، ریشه همان کاری است که ما انجام می دهیم و این اتفاق بیفتد، اما نباید تمرکز همه فعالیت های شما، فقط تجریه و تحلیل علت موضوع باشد. به عنوان مثال، قبل از اینکه دلیل اصلی ریشه درک کنید، باید تقریبا همیشه راه حل را پیش بینی کنید.
بنابراین اگر این مشکل دوباره اتفاق می افتد، به کارکنان سرویس دهنده بگویید چه باید بکنید. شما ممکن است این مشکل را کاملا درست نکنید، اما اگر خودتان و یا بهترین افراد فنی خود را معطل یافتن علل ریشه ای مشکل برای یک مدت خاص بکنید راندمان فعلی شما هم زیر سئوال می رود. یک آمپول موقت حجم تکرار حوادث را می گیرد بی آنکه دقیقا علل مشکل را یافته باشید و بی آنکه زمان و انرژی و منابع زیادی هم تخصیص داده باشید قادرید تا با این فن سریع، تاثیر حوادث را بر کسب و کار به حداقل برسانید، در نهایت پس از آنکه شدت و تاثیر انبوه آن از بین رفت آنگاه زمان بیشتری را برای حل مشکل خواهید داشت و با خیال آسوده تر و استرس کمتر به دنبال راه حل های موثر و ریشه ای بگردید.
پس بخاطر بسپارید تمرکز کامل بر روی مشکل سبب توقف شما می شود که تاثیر منفی بر کسب و کار سازمان می گذارد.
کارکنان خود را در زمینه تکنیک های حل مسئله آموزش دهید. به آنها اطمینان دهید تا اجزای فن آوری را بهتر درک کنند و بسیاری از آموزش های مدیریت خدمات را را به آنها بیاموزید تا اطمینان حاصل شود که فرایندهایی که آنها دنبال می کنند را درک می کنند و میدانند کی، کجا و چگونه آنها را در سازمان بکار بگیرند.
متاسفانه به طرز قابل توجهی تعداد کمی از کارکنان فنی در آموزش های رسمی در مورد چگونگی تجزیه و تحلیل مشکلات شرکت می کنند علل زیادی دارد که شامل:
اما من به شخصه با درک موارد فوق، تعدادی از رویکردهای موجود را پیشنهاد می کنم که می تواند موثر باشند، علاقه شخصی من به حل مشکل از طریق روش های آموزشی Kepner-Tregoe و تحلیل Timeline است، اما رویکردهای دیگر می توانند به همان اندازه موثر باشند.
دقت کنید نرم افزارها، الگوها و فرایندها، مشکلات را حل نمی کنند. مردم هستند که مشکلات را حل می کنند!
چه نوع مردمی؟ افرادی که کنجکاو هستند، آنهایی که ذهنی پرسشگر دارند و سوالاتی را مطرح می کنند و بر اساس حقایق تصمیم گیری می کنند، آنهایی که دید وسیع تری نسبت به حوزه کاری خود دارند و به آنها قدرت می دهند که رهبری کنند. آنها تحت فشار قرار می گیرند و با اطمینان عمل می کنند تا آنچه را که باید انجام شود را انجام دهند.
مدیریت دانش، می تواند اطمینان حاصل کند که اطلاعات مناسب برای افرادی که به آن نیاز دارند در دسترس خواهد بود و برای آنها ارزشمند خواهد بود. این امر می تواند به بهبود مدیریت حادثه کمک کند و به شما اجازه می دهد تا برای سرویس دهی خدمات خود به اطلاعاتی دست یابید که کمک حال است و مفید! تا سریعتر به تصادفات برسید. همچنین می تواند برای پشتیبانی از یک پورتال خود خدمتی یا Self-Service Portal استفاده شود تا کاربران نهایی بتوانند حوادث خود را حل کنند.
مدیریت دانش احتمالا تعداد حوادث را کاهش نخواهد داد، اگرچه ممکن است با ارائه اطلاعات و راهکارها به کاربرانی که نیاز به استفاده از خدمات به طور موثر دارند، تأثیری داشته باشد. آنچه که مدیریت دانش در حقیقت قرار است انجام دهد:
یک رویکرد بسیار موثر در استفاده از مدیریت دانش در فناوری اطلاعات سازمان ها ، پشتیبانی دانش محور (KCSsm) است. شما به یک پروژه بزرگ نیاز ندارید تا شروع کنید به بهبود چگونگی مدیریت دانش، بنابراین ایجاد یک پروژه بزرگ بنام مستند سازی و تولید راهکار و مدیریت دانش در ابتدای کار، نفس گیر و ناکاؤامد خواهد بود.
مدیریت دانش بصورت منطقه ای است یعنی در هر حوزه و در هر بخش متفاوت خواهد بود پس با یک رویکرد هوشمندانه در مدیریت خدمات IT می تواند به خوبی کار کند. پس برای بهره مندی از مدیرت دانش کارآمد، فکر کنید که این دانش چه چیزی را بهبود می بخشد و ببیند که چگونه می توانید آن را فراهم کنید، سپس به دنبال دانش بیشتری باشید تا ارزش بیشتری را ایجاد کنید. در نهایت شما ممکن است نیاز به سرمایه گذاری در ابزار و فرآیند رسمی تر داشته باشید، اما با چیزی ساده شروع کنید.
فرهنگ مستند سازی، ارایه راهکار قدم اول در مدیریت پایگاه دانش از کلیدی ترین گامهاست بنابراین انرژی کاملی را همان ابتدای کار بر روی این موضوع نگذارد زمانیکه این فرهنگ نهادینه شد آنگاه سراغ ابزارها و راهکارهای حرفه ای برای تولید و مستندسازی راه حل ها بروید تا استاندارد کار کنید.
در بسیاری از فناوری اطلاعات سازمان ها، بزرگترین علت شکست سرویس، تغییراتی است که اشتباه است. برآورد اینکه چه میزان از حوادث ناشی از تغییر است متفاوت است، اما من شخصا، بیش از ۸۰٪ کاهش در حوادث ناشی از تغییر در یک سازمان را دیده ام، بنابراین مدیریت صحیح تغییر می تواند نتایج بسیار قابل توجه ای ارایه کند.
اما متاسفانه بسیاری از افراد حاضر در فناوری اطلاعات، مدیریت تغییر را بیش از حد، دیوانه وار انجام می دهند، ارتقا ویندوزهای سرور، استفاده از ابزارها و راه اندازی سرویس های و تغییرات پیکربندی های سوئیچ و روترها و زیرساخت شبکه و… از آن دسته هستند که با پذیرفتن ریسک (خطر) بالا، باعث ایجاد تغییرات می شود. آنچه که شما نیاز دارید یک فرایند مدیریت تغییرات کارآمد و موثر است که به شما کمک می کند تغییراتی را که ریسک و خطری برای مشتریان شما ندارد را انجام دهید. این دشوار است اما غیر ممکن نیست. چیزی که می توانید انجام دهید این است که از تحلیل روند استفاده کنید تا مشخص شود که کدام تغییرات، احتمال خرابی را افزایش می دهد و تمرکز تلاش های خود را در کاهش خطر در آن مناطق معطوف کنید، و راه سریع را برای تغییراتی که خطر کمتری دارند بیابید.
فراموش نکنید بخش عظیمی از حوادث ناشی از تغییرات خودسرانه در سرویسها و زیرساخت هاست که علاوه بر پیامدهای منفی، فرکانس تکرار حوادث جدیدی را افزایش و سبب نارضایتی مشتری و در نهایت شکست تغییر می شود.
بهترین کاری که می توانید برای کاهش فرکانس و تاثیر حوادث انجام دهید این است که اولویت خدمات خود را طراحی کنید، اما به دلایلی، بسیاری از فناوری اطلاعات سازمان ها، تصمیم به سرمایه گذاری در برنامه ریزی برای جلوگیری از شکست نمی کنند، ترجیح می دهند که پول خود را برای به حالت عادی درآوردن وضعیت پس از وقوع حوادث نمایند!
ITIL فرآیندهایی را برای مدیریت دسترسی و مدیریت ظرفیت ارایه کرده اما تعداد کمی از سازمان ها خدمات در دسترس را فراهم می کنند و بیشتر کار مدیریت ظرفیت آنها، صرفا فنی است و داده های کسب و کار کمی برای پیش بینی واقعی نیازهای آینده فراهم می کنند.
چیزهای زیادی وجود دارد که می توان برای بهبود طرح ها انجام داد. ساده ترین طرح ها صرفا این است که مطمئن شوید که کارهای افزونگی و انعطاف پذیری که شما انجام داده اید، در واقع بطور درست کار می کنند. برای مثال دیسک ها ممکن است در مجموعه های RAID پیکربندی شوند، اما هیچ کس متوجه نشده است که یکی از دیسک از کار افتاده! یا ممکن است مرتباً از دیتابیس ها مختلف در حال گرفتن بک آپ هستید بی آنکه بدانید که این بک آپ ها کار میکنند یا خیر!، یا یک شبکه ممکن است لینک های دوگانه بین سایت ها داشته باشد، اما یکی از لینک ها دیگر کار نمی کند و تا زمانی که لینک اصلی از کار نیفتد شما متوجه خرابی لینک مازاد نخواهید شد! در این حال نیاز هست تا یک حسابرسی کارآمد داشته باشید اگر حسابرسی این اقدامات را در محیط خود انجام ندهید، نمی توانید بفهمید که کنترل های فنی شما چگونه کار می کنند – پس با ایجاد PM های منظم و حسابرسی بر تولید فرم های درخواست خدمات، ممکن است خود و مشتری و یا سازمان را از یک خرابی گران نجات دهید! بنابراین شما می توانید یک طرح در دسترس بودن را ایجاد کنید که به طور منظم از همه اقدامات شکست خورده پشتیبانی می کند، به صورت خودکار یا دستی.
یک داستان: در یکی از سازمان های دولتی، که پشتیبانی شبکه را به یک شرکت پیمانکار فناوری سپرده بود و یکی از مهمترین مفاد قرارداد فی مابین آنها، پشتیبان گیری از دیتابیس ۱۰ نرم افزار سازمانی بود که می بایست هر روز تهیه می شد و کارشناسان پشتیبانی پیمانکار هر روز بطور خودکار و منظم این پشتیبان گیری را انجام و بر روی DVD ذخیره می کردند! تا آنکه در یکی از روزها، پورتال این سازمان هک شد و تمامی اطلاعات از بین رفت سریعا پیمانکار در جریان مشکل قرار گرفت و خواست تا آخرین بک آپ را بازگرداند و وضعیت به حالت عادی برگردد غافل از اینکه فایلهای بک آپ کار نمی کند!
تصور کنید چه خرابی بزرگی به پا شده!
نوآوری اخیر در طراحی در دسترس بودن، ایده ایجاد راه حل های ضد شکست است. این یک فلسفه بسیار متفاوت برای مدیریت دسترسی سنتی است. مفهوم اصلی این است که ایجاد راه حل هایی است تا شکست نتواند هرگز موفق نشود! چراکه یک شکست موفق! در نهایت منجر به یک فاجعه با تاثیر عظیم تجاری می شود. پس طراحی یک راه حل ضد شکست همواره همراه با دانش است که همه چیز را ناکام می گذارد، بنابراین با طراحی این راه حل، بهبود بسیار سریع و با حداقل تاثیر بر روی کسب و کار اولویت بسزایی دارد که تمرکز بر زمان متوسط برای بازگرداندن سرویس (MTRS) به جای زمان متوسط بین شکست (MTBF) است. در حالت ایده آل، یک راه حل ضد شکننده، در هنگام وقوع یک شکست به صورت خودکار، وضعیت را بهبود داده و قبل از اینکه کاربران حتی متوجه شوند که شکستی رخ داده اوضاع را به حالت عادی باز می گرداند.
در سناریو داستان اشاره شده، تست بک آپ های گرفته شده در هر روز ولو بصورت دستی و استفاده از راهکارهایی نظیر SAN یا NAS می توانست آبروی شرکت پیمانکار را بخرد! در حالیکه هیچکدام نبود بخصوص اینکه آن پیمانکار درک درستی از مدیریت دسترسی و طراحی خدمات نداشت!
اکثر فناوری اطلاعات سازمان بیش از اندازه وقت و تلاش در مدیریت حوادث را صرف می کنند که هیچ ارزش خالصی را برای مشتریان ایجاد نمی کند اما اگر ما همه چیز را در مورد اقداماتی برای کاهش فرکانس و تاثیرات تجاری حوادث، سرمایه گذاری کنیم، بی شک مشتریان ما خدمات بسیار بهتر را دریافت خواهند کرد و حتی ممکن است هزینه کل ارائه فناوری اطلاعات را کاهش داد.
چیزهای بسیار مختلفی هستند که می توانید امتحان کنید، و هر یک از آنها باعث افزایش بهبود در خدمات شما می شود. باید در مورد چگونگی انجام مدیریت مدیریت حوادث و ایجاد ارزش بیشتر برای مشتریان خود فکر کنید و به سازمان باشید چون با رشد سازمان شما نیز رشد می کنید.
با مدیریت حوادث کمتر، ماهیت مهندس بودن خود را بیشتر در فناوری اطلاعات نشان دهید تا آتش نشان بودن را!
شما نیز تجربیات خود را در این خصوص با ما در میان بگذارید.
هادی احمدی
[…] آتشنشانان فناوری اطلاعات […]
[…] آتشنشانان فناوری اطلاعات […]
[…] چرا باید مدیریت حوادث کمتری انجام دهید؟ […]
[…] چرا باید مدیریت حوادث کمتری انجام دهید؟ […]
[…] در فناوری اطلاعات آتشنشان نباشید! […]