خیلی از سازمانها و کسب و کارها به تعداد نیروهای پشتیبانی می‌نازند و خیلی‌ها به تعداد پاسخ به تیکت‌هایشان که به کاربر/مشتری ارایه میدهند، برخی شاخص‌های عملکرد را بر اساس تعداد و حجم درخواست‌ها و ظرفیت و گنجایش هر کارشناس واحد انفورماتیک می‌دانند و برخی سرعت در پاسخ به خرابی‌ها را در کارنامه خود در بوق و کرنا می‌دمند، اینکه بسیاری از سازمانها در مدیریت حوادث بسیار خوب عمل میکنند، خبر خوبی است اما نه همیشه! مشکل اینجاست که افراد آنقدر مشغول برخورد با حوادث روزمره می شوند که وقت لازم را برای جلوگیری و ایستادن جلوی وقوع چنین حوادثی را ندارند.
برای خود این مشکل چه مدیریت مشکلی می توان داشت!؟
ادامه در لینک زیر
https://lnkd.in/eVHb_AKA
برای خود این مشکل چه مدیریت مشکلی می توان داشت!؟
ادامه در لینک زیر
https://lnkd.in/eVHb_AKA
Forwarded from [ S o r o u s h a n e ]
با گذشت سال‌ها هنوز هم مدیران ارشد و حتی خود مدیران فناوری اطلاعات، یک تجهیز سخت‌افزاری را خیلی سریع‌تر و راحت‌تر می‌خرند چون قابل لمس است و بُعد فیزیکی آن را می‌بینند، ازاین‌رو هزینه‌کرد برای خرید آن را قابل توجیه می‌دانند در حالی‌که این موضوع درخصوص نرم‌افزار برعکس است. یعنی برای خرید نرم‌افزار هزار بار به زمین و زمان چنگ می‌اندازد تا نخرند و یا ارزان‌ترین و ناکارآمدترینش را خریداری کنند زیرا هزینه‌کرد برای مصارف نرم‌افزاری را بیهوده می‌دانند!
یکی نیست به آنان بگوید سرور n میلیونی برای نگهداری و اجرای چه چیزی خریدی!؟
نرم‌افزار یا هوا!؟
یا فلان تجهیز امنيتي چندمیلیاردی را خریدی که از چه چیزی محافظت کنی؟
آدم عاقل، گاوصندوق نمی‌خرد که توی آن هیچی نگذارد!
×××
تناسب بین خرید تجهیز سخت‌افزاری و سرویس نرم‌افزاری یک امر حیاتی در مدیریت مالی است. رعایت این توازن و تناسب باعث می‌شود سخت‌افزاری نخرید که شکل دکوری باشد و یا نرم‌افزاری نخرید که حداکثر یک فرمش را اجرا کنید. توازن خرید نرم‌افزار و سخت‌افزار کلید حل مدیریت هزینه است.
هر چیز لمس‌شدنی، همه چیز را به شما نمی‌دهد.
امان از مدیرانی که گاه یک تریلی را از سوراخِ سوزن رد میکنند و گاهی از درِ دروازه نه.
www.Soroushane.ir
یکی نیست به آنان بگوید سرور n میلیونی برای نگهداری و اجرای چه چیزی خریدی!؟
نرم‌افزار یا هوا!؟
یا فلان تجهیز امنيتي چندمیلیاردی را خریدی که از چه چیزی محافظت کنی؟
آدم عاقل، گاوصندوق نمی‌خرد که توی آن هیچی نگذارد!
×××
تناسب بین خرید تجهیز سخت‌افزاری و سرویس نرم‌افزاری یک امر حیاتی در مدیریت مالی است. رعایت این توازن و تناسب باعث می‌شود سخت‌افزاری نخرید که شکل دکوری باشد و یا نرم‌افزاری نخرید که حداکثر یک فرمش را اجرا کنید. توازن خرید نرم‌افزار و سخت‌افزار کلید حل مدیریت هزینه است.
هر چیز لمس‌شدنی، همه چیز را به شما نمی‌دهد.
امان از مدیرانی که گاه یک تریلی را از سوراخِ سوزن رد میکنند و گاهی از درِ دروازه نه.
www.Soroushane.ir
اگر یک َرک بالا بلند! با دهها سرور و سوییچ خریداری و پیاده‌سازی کرده‌اید اما ابزاری برای مدیریت امنیت آن، مدیریت دسترسی، گزارش‌گیری، کنترل و نظارت مستمر و دائم برای آن در نظر نگرفته‌اید یا موقت در نظر گرفته‌اید. همان داستان دیوار چین را تداعی کرده‌اید.
اگر برای رشد سازمان یک ابزار گران‌قیمت ITIL را خریده‌اید اما همچنان Business As Usual کار می‌کنید. داستان دیوار چین را تکرار کرده‌اید.
تجهیزات، ابزارها و اتوماسیون‌ها همگی خوب هستند و گره‌گشای بسیاری از مشکلات. اما اگر قبل از اینکار و پشت بندش، تحول دیجیتال در نظم فکری مدیران و کارکنان نباشد و به همان شیوه‌ی مرسوم ادامه دهند و روش مدیریتی و حمایت انسانی را نداشته باشد باز دیوار چین را ساخته‌اید.
دقت کنید ساخت دیوار چین یک خروجی است اما شکسته شدن یا نشدن آن نتیجه است! و نتیجه مهمتر از خروجی است.
اگر هر سال بدنبال جذب یک پیمانکار با کمترین قیمت هستید اما کاری برای کاهش ترافیک خرابی‌ها و تلاشی برای بهبود نشده، فقط آجر رو آجر گذاشته‌اید! آنهم با کارگران ارزان و دستمزد کم.
ادامه از لینک زیر
https://lnkd.in/e-k-fB6
اگر برای رشد سازمان یک ابزار گران‌قیمت ITIL را خریده‌اید اما همچنان Business As Usual کار می‌کنید. داستان دیوار چین را تکرار کرده‌اید.
تجهیزات، ابزارها و اتوماسیون‌ها همگی خوب هستند و گره‌گشای بسیاری از مشکلات. اما اگر قبل از اینکار و پشت بندش، تحول دیجیتال در نظم فکری مدیران و کارکنان نباشد و به همان شیوه‌ی مرسوم ادامه دهند و روش مدیریتی و حمایت انسانی را نداشته باشد باز دیوار چین را ساخته‌اید.
دقت کنید ساخت دیوار چین یک خروجی است اما شکسته شدن یا نشدن آن نتیجه است! و نتیجه مهمتر از خروجی است.
اگر هر سال بدنبال جذب یک پیمانکار با کمترین قیمت هستید اما کاری برای کاهش ترافیک خرابی‌ها و تلاشی برای بهبود نشده، فقط آجر رو آجر گذاشته‌اید! آنهم با کارگران ارزان و دستمزد کم.
ادامه از لینک زیر
https://lnkd.in/e-k-fB6
با توجه به رشد 3 درصدی هزینه‌های جهانی فناوری اطلاعات تا سال 2021 و بیش از 3.5 تریلیون دلار، هیچ زمانی از این بهتر برای اجرای مدیریت مالی ITIL وجود ندارد. مزایایی که با اجرای چارچوب ITIL برای مدیریت مالی به دست می‌آید عبارت‌اند از:
ادامه در لینک زیر
https://lnkd.in/eHthkHvM
ادامه در لینک زیر
https://lnkd.in/eHthkHvM
معیار غلط فدای همه چیز!؟
اگرچه جمله‌ی معروف پیتردراکر این است که:"بدون اندازه‌گیری نمی‌شود مدیریت کرد!" اما این را نباید به اشتباه تعمیم داد. زیرا در دنیای علوم اجتماعی، قانون کمپبل بیان می‌کند: "هنگامی‌که یک متریک به‌عنوان شاخص اولیه موفقیت شناخته شود، توانایی آن برای اندازه‌گیری دقیق موفقیت، به خطر می‌افتد." همچنین یک قانون مشابه در حوزه اقتصاد بنام قانون گودرث می‌گوید:" وقتی اندازه‌گیری یک هدف است، توقف آن، بهترین اندازه‌گیری است."
×××
شاخص‌های اندازه‌گیری اگرچه خوبند اما معیارهای ضعیف ممکن است سبب تقویت رفتار اشتباه شود. به‌عنوان‌مثال، سرعت در پاسخگویی به نرخ حوادث، ریسک از دست دادن اطلاعات حیاتی را افزایش می‌دهد و یا سبب عدم استفاده از راه‌حل مشکلات موجود و خطاهای شناخته‌شده می‌شود.
اگر کارشناسان پشتیبانی و سرویس‌دهندگان فقط روی سرعت تمرکز کنند، چیزهایی مانند خلاقیت، اضافه کردن یادداشت‌های مناسب، بررسی پایگاه دانش، ایجاد راهکار، شناسایی علت حادثه، ریشه‌یابی و واگذاری حادثه به یک مشکل و یا حتی تخصیص چند ثانیه اضافی برای تلاش و اصلاح حادثه در همان بار نخست از بین می‌رود.
×××
ضمن اینکه با گذشت زمان، این امر منجر به کاهش کیفیت خدمات عمومی و افزایش زمان صرف شده برای بازگرداندن حوادث می‌شود. تازه فقط این نیست شما از تکنسین‌های پشتیبانی و سرویس‌دهندگان تعدادی ربات-تکنسین خط تولید می‌سازید که انگیزه‌های شغلی آنها را در حاکمیت مطلق فاقد معیارهای بهبود و توسعه‌ی مستمر، بطور کل نابود خواهید کرد. در نتیجه ابتکار، خلاقیت، پویایی و ارائه راهکارهای بهینه برای همیشه از بین می‌رود چراکه بر اساس مفاهیم ITSM هدف از اجرای تمامی فرایندها، بهبود مستمر است.
www.MedaNet.ir
اگرچه جمله‌ی معروف پیتردراکر این است که:"بدون اندازه‌گیری نمی‌شود مدیریت کرد!" اما این را نباید به اشتباه تعمیم داد. زیرا در دنیای علوم اجتماعی، قانون کمپبل بیان می‌کند: "هنگامی‌که یک متریک به‌عنوان شاخص اولیه موفقیت شناخته شود، توانایی آن برای اندازه‌گیری دقیق موفقیت، به خطر می‌افتد." همچنین یک قانون مشابه در حوزه اقتصاد بنام قانون گودرث می‌گوید:" وقتی اندازه‌گیری یک هدف است، توقف آن، بهترین اندازه‌گیری است."
×××
شاخص‌های اندازه‌گیری اگرچه خوبند اما معیارهای ضعیف ممکن است سبب تقویت رفتار اشتباه شود. به‌عنوان‌مثال، سرعت در پاسخگویی به نرخ حوادث، ریسک از دست دادن اطلاعات حیاتی را افزایش می‌دهد و یا سبب عدم استفاده از راه‌حل مشکلات موجود و خطاهای شناخته‌شده می‌شود.
اگر کارشناسان پشتیبانی و سرویس‌دهندگان فقط روی سرعت تمرکز کنند، چیزهایی مانند خلاقیت، اضافه کردن یادداشت‌های مناسب، بررسی پایگاه دانش، ایجاد راهکار، شناسایی علت حادثه، ریشه‌یابی و واگذاری حادثه به یک مشکل و یا حتی تخصیص چند ثانیه اضافی برای تلاش و اصلاح حادثه در همان بار نخست از بین می‌رود.
×××
ضمن اینکه با گذشت زمان، این امر منجر به کاهش کیفیت خدمات عمومی و افزایش زمان صرف شده برای بازگرداندن حوادث می‌شود. تازه فقط این نیست شما از تکنسین‌های پشتیبانی و سرویس‌دهندگان تعدادی ربات-تکنسین خط تولید می‌سازید که انگیزه‌های شغلی آنها را در حاکمیت مطلق فاقد معیارهای بهبود و توسعه‌ی مستمر، بطور کل نابود خواهید کرد. در نتیجه ابتکار، خلاقیت، پویایی و ارائه راهکارهای بهینه برای همیشه از بین می‌رود چراکه بر اساس مفاهیم ITSM هدف از اجرای تمامی فرایندها، بهبود مستمر است.
www.MedaNet.ir
پارکینسون مدیریت هم بیماری است!
قانون پارکینسون یا Parkinson's law یک مفهوم رایج در مدیریت و بالاخص کنترل پروژه است و مضمون آن این است که «هر کاری به‌اندازه زمانی که برای آن درنظر گرفته شده طول می‌کشد.»
نام این قانون از نام تاریخدان انگلیسی سیریل نورث‌کوت پارکینسون گرفته‌شده که زمینه‌ی گسترش بی‌رویه بوروکراسی را بیان می‌کند. اجرای ناخودآگاه این قانون، سازمان را بیمار خواهد کرد. زیرا که از دید این «قانون» انجام هر کاری تا زمانی که برای آن تعیین‌شده، طول می‌کشد و این مدت زمان ارتباط چندانی با میزان و ماهیت کار ندارد. این یعنی هر چقدر کش‌اش بدهی به همان اندازه‌ی زمان نیاز داری! استفاده‌ی نادرست از این قانون بی‌قانونی بهمراه می‌آورد. زیرا منجر به گسترش بوروکراسی‌ها می‌شود و تلخ‌تر این است که این توسعه‌ی بوروکراسی‌ها بدون گسترش اهداف است.
پارکینسون در سازمان، یعنی تمایل رئیسان به داشتن مرئوسان بیشتر که باانگیزه‌ی توسعه‌ی دپارتمان خود سعی در بزرگ جلوه دادن خود میکنند، اما غافلند که این سبب گسترش بوروکراسی‌ها می‌شود و گسترش بوروکراسی منجر به افزایش کارکنان و ایجاد وظایف تکراری و صدالبته لختی در انجام کار می‌شود.
دولت اختاپوسی ایران و بسیاری از سازمان‌های عریض و طویل دولتی دقیقاً بهترین نمونه‌‌ها از قانون یا بیماری پارکینسون هستند!
×××.
بطور مثال بر اساس این قانون در حوزه فناوری، داده‌ها برای پر کردن فضای موجود برای ذخیره‌سازی همیشه درحال افزایشند! یا تقاضا برای یک منبع تمایل دارد تا متناسب باعرضه منبع باشد. این تعمیم شبیه به چیزی است که برخی اقتصاددانان آن را قانون تقاضا می‌دانند - یعنی هرچه قیمت خدمات یا کالا پایین‌تر باشد، مقدار تقاضا بیشتر می‌شود. به این خواسته القایی نیز گفته می‌شود.
از آنجایی که با پارکینسون مقدار زمانی که شخص برای انجام یک کار باید انجام دهد، همان مقدار زمان لازم برای انجام آن کار است لذا برای پیشگیری از این بیماری زمان‌های را که تخصیص می‌دهید نباید آنقدر طولانی باشد که نقطه‌ی مرگ نداشته باشد و منابع انسانی را به‌اندازه‌ی معقولی به پروژه‌ها تخصیص دهید.
×××
همان‌طور که گفتم، قانون پارکینسون شبیه بیماری پارکینسون، سازمان را دچار لقوه‌گی، تعلل و اختلال پیش‌رونده و مخرب در درازمدت می‌کند! هر دو نوع بیماری در صورت ابتلا، درمان ندارند اما با تمهیداتی می‌توان از وقوع آن پیشگیری کرد. مثلاً با کاهش منابع انسانی کم‌مصرف. استفاده‌ی بهینه از کارایی و توانایی افراد با مشوق‌های مالی و معنوی، استفاده از ابزارهای مدیریت سطح ارایه خدمات و مدیریت پروژه برای بهبود مستمر با چارچوب ITIL، ورزش دادن اندیشه‌ی مدیران برای حذر از بزرگنمایی دارودسته‌های زیرمجموعه. تمرکز بر کوچک‌سازی، استفاده از اسکرام و چارچوب Agile.
این بیماری را جدی بگیرید!
www.MedaNet.ir
قانون پارکینسون یا Parkinson's law یک مفهوم رایج در مدیریت و بالاخص کنترل پروژه است و مضمون آن این است که «هر کاری به‌اندازه زمانی که برای آن درنظر گرفته شده طول می‌کشد.»
نام این قانون از نام تاریخدان انگلیسی سیریل نورث‌کوت پارکینسون گرفته‌شده که زمینه‌ی گسترش بی‌رویه بوروکراسی را بیان می‌کند. اجرای ناخودآگاه این قانون، سازمان را بیمار خواهد کرد. زیرا که از دید این «قانون» انجام هر کاری تا زمانی که برای آن تعیین‌شده، طول می‌کشد و این مدت زمان ارتباط چندانی با میزان و ماهیت کار ندارد. این یعنی هر چقدر کش‌اش بدهی به همان اندازه‌ی زمان نیاز داری! استفاده‌ی نادرست از این قانون بی‌قانونی بهمراه می‌آورد. زیرا منجر به گسترش بوروکراسی‌ها می‌شود و تلخ‌تر این است که این توسعه‌ی بوروکراسی‌ها بدون گسترش اهداف است.
پارکینسون در سازمان، یعنی تمایل رئیسان به داشتن مرئوسان بیشتر که باانگیزه‌ی توسعه‌ی دپارتمان خود سعی در بزرگ جلوه دادن خود میکنند، اما غافلند که این سبب گسترش بوروکراسی‌ها می‌شود و گسترش بوروکراسی منجر به افزایش کارکنان و ایجاد وظایف تکراری و صدالبته لختی در انجام کار می‌شود.
دولت اختاپوسی ایران و بسیاری از سازمان‌های عریض و طویل دولتی دقیقاً بهترین نمونه‌‌ها از قانون یا بیماری پارکینسون هستند!
×××.
بطور مثال بر اساس این قانون در حوزه فناوری، داده‌ها برای پر کردن فضای موجود برای ذخیره‌سازی همیشه درحال افزایشند! یا تقاضا برای یک منبع تمایل دارد تا متناسب باعرضه منبع باشد. این تعمیم شبیه به چیزی است که برخی اقتصاددانان آن را قانون تقاضا می‌دانند - یعنی هرچه قیمت خدمات یا کالا پایین‌تر باشد، مقدار تقاضا بیشتر می‌شود. به این خواسته القایی نیز گفته می‌شود.
از آنجایی که با پارکینسون مقدار زمانی که شخص برای انجام یک کار باید انجام دهد، همان مقدار زمان لازم برای انجام آن کار است لذا برای پیشگیری از این بیماری زمان‌های را که تخصیص می‌دهید نباید آنقدر طولانی باشد که نقطه‌ی مرگ نداشته باشد و منابع انسانی را به‌اندازه‌ی معقولی به پروژه‌ها تخصیص دهید.
×××
همان‌طور که گفتم، قانون پارکینسون شبیه بیماری پارکینسون، سازمان را دچار لقوه‌گی، تعلل و اختلال پیش‌رونده و مخرب در درازمدت می‌کند! هر دو نوع بیماری در صورت ابتلا، درمان ندارند اما با تمهیداتی می‌توان از وقوع آن پیشگیری کرد. مثلاً با کاهش منابع انسانی کم‌مصرف. استفاده‌ی بهینه از کارایی و توانایی افراد با مشوق‌های مالی و معنوی، استفاده از ابزارهای مدیریت سطح ارایه خدمات و مدیریت پروژه برای بهبود مستمر با چارچوب ITIL، ورزش دادن اندیشه‌ی مدیران برای حذر از بزرگنمایی دارودسته‌های زیرمجموعه. تمرکز بر کوچک‌سازی، استفاده از اسکرام و چارچوب Agile.
این بیماری را جدی بگیرید!
www.MedaNet.ir
بده بغلی!
یکی از آفت‌هایی که باعث شکست پروژه می‌شود این است:"بده بغلی!"
شانه خالی کردن از زیر بار وظایف و تسک‌های مرتبط توسط افراد به بهانه‌هایی نظیر: وقت ندارم، سرم شلوغ است، جلسه‌ام؛ فلانی بهتر انجام می‌دهد؛ من بلد نیستم؛ کار دیگری پیش‌آمده، هنوز بررسی نشده، باید بروم؛ بخدا نمی‌رسم؛ می‌خواهم حال طرف را بگیرم؛ خسته‌ام، دست‌تنهایم، هنوز فلانی دستورش را نداده و ... همگی برای برون‌رفت از وظیفه‌ی محوله‌ای است که سعی دارد به‌گونه‌ای از انجام آن خودداری و یا با تعلل بسیار آن را به تعویق اندازد و اولین کاری که می‌کند این است که بدون هیچ بررسی اولیه، آن کار را به بغلی پاس می‌دهد!
×××
پاسکاری وظایف و درخواست‌ها یک عارضه است و در هر کسب‌وکاری و حتی در زندگی شخصی هم به‌وفور دیده می‌شود و همین امر سبب افزایش سطح نارضایتی و دلخوری از انجام درست و به‌موقع مسئولیت‌ها می‌شود. این درنهایت یعنی بی‌اعتمادی به پروژه یا فرد!
بده به بغلی، یک‌رویه‌ی فکری بیمارگونه است که فرد بجای مواجهه با وظایفش سعی دارد آن را به بغلی ارجاع دهد. تصور کنید اگرچند نفر از این افراد در هر مجموعه‌ای باشند یعنی فاجعه. چیزی که در ارگان‌های دولتی که مبتلا به بیماری پارکینسون مدیریت هستند و در منجلاب بوروکراسی دست‌وپا هم نمی‌زنند، بسیار دیده می‌شود.
×××
بده به بغلی، اگر منجر به شکست پروژه نشود، اما درهرصورت، اجرای به‌موقع آن را سؤال خواهد برد. چه‌بسا که بسیاری از پروژه‌ها شبیه بسیاری از آرزوها اگر در زمان مقرر برآورده نشوند، فرقی با برآورده شدن‌شان ندارند!
با ابزارهای مدیریت خدمات سازمانی و چارچوب ITIL و تعیین شاخص‌های عملکرد و گزارش‌گیری و تحلیل حجم پاس‌کاری‌ها، جلوی این آفت شُوم را بگیرید. بهتر است این افراد را شناسایی و یا بغلی آنان را از او دور کنید!
کاری کنید که نده بغلی!
www.MedaNet.ir
یکی از آفت‌هایی که باعث شکست پروژه می‌شود این است:"بده بغلی!"
شانه خالی کردن از زیر بار وظایف و تسک‌های مرتبط توسط افراد به بهانه‌هایی نظیر: وقت ندارم، سرم شلوغ است، جلسه‌ام؛ فلانی بهتر انجام می‌دهد؛ من بلد نیستم؛ کار دیگری پیش‌آمده، هنوز بررسی نشده، باید بروم؛ بخدا نمی‌رسم؛ می‌خواهم حال طرف را بگیرم؛ خسته‌ام، دست‌تنهایم، هنوز فلانی دستورش را نداده و ... همگی برای برون‌رفت از وظیفه‌ی محوله‌ای است که سعی دارد به‌گونه‌ای از انجام آن خودداری و یا با تعلل بسیار آن را به تعویق اندازد و اولین کاری که می‌کند این است که بدون هیچ بررسی اولیه، آن کار را به بغلی پاس می‌دهد!
×××
پاسکاری وظایف و درخواست‌ها یک عارضه است و در هر کسب‌وکاری و حتی در زندگی شخصی هم به‌وفور دیده می‌شود و همین امر سبب افزایش سطح نارضایتی و دلخوری از انجام درست و به‌موقع مسئولیت‌ها می‌شود. این درنهایت یعنی بی‌اعتمادی به پروژه یا فرد!
بده به بغلی، یک‌رویه‌ی فکری بیمارگونه است که فرد بجای مواجهه با وظایفش سعی دارد آن را به بغلی ارجاع دهد. تصور کنید اگرچند نفر از این افراد در هر مجموعه‌ای باشند یعنی فاجعه. چیزی که در ارگان‌های دولتی که مبتلا به بیماری پارکینسون مدیریت هستند و در منجلاب بوروکراسی دست‌وپا هم نمی‌زنند، بسیار دیده می‌شود.
×××
بده به بغلی، اگر منجر به شکست پروژه نشود، اما درهرصورت، اجرای به‌موقع آن را سؤال خواهد برد. چه‌بسا که بسیاری از پروژه‌ها شبیه بسیاری از آرزوها اگر در زمان مقرر برآورده نشوند، فرقی با برآورده شدن‌شان ندارند!
با ابزارهای مدیریت خدمات سازمانی و چارچوب ITIL و تعیین شاخص‌های عملکرد و گزارش‌گیری و تحلیل حجم پاس‌کاری‌ها، جلوی این آفت شُوم را بگیرید. بهتر است این افراد را شناسایی و یا بغلی آنان را از او دور کنید!
کاری کنید که نده بغلی!
www.MedaNet.ir
آستین خالی سازمان!
براساس ارزیابی آژانس فناوری اطلاعات Recovery Avaya بیش از ۵۲٪ وقفه‌های بلندمدت در شبکه بدلیل عدم وجود سخت‌افزار و یا تجهیزات بکاپ است، که از این میزان ۴۸٪ منجر به تحمیل هزینه‌های سنگین و بی‌بازگشت می‌شود.
بطور مثال با از کار افتادن روتر، پرینتر، سرور و یا سوییچ، فرایند ثبت درخواست تامین، تایید و خرید یک تجهیز جایگزین منجر به وقوع این اختلال بلندمدت می‌شود. داشتن تجهیزات پشتیبان اگرچه در ابتدا هزینه‌ای روی دست سازمان می‌گذارد اما این رقم در قیاس با توقف سرویس ناچیزست. داشتن تجهیزات بکاپ، به میزان قابل‌توجهی می‌تواند نرخ بازگشت‌پذیری سرمایه، اعتماد مشتریان و همچنین نرخ دردسترس پذیری سرویس را به شدت افزایش دهد.
اگر سرویس‌های آنلاین و یا حیاتی سازمانی دارید، همیشه تجهیزات بکاپ در آستین سازمان داشته باشید!
www.MedaNet.ir
براساس ارزیابی آژانس فناوری اطلاعات Recovery Avaya بیش از ۵۲٪ وقفه‌های بلندمدت در شبکه بدلیل عدم وجود سخت‌افزار و یا تجهیزات بکاپ است، که از این میزان ۴۸٪ منجر به تحمیل هزینه‌های سنگین و بی‌بازگشت می‌شود.
بطور مثال با از کار افتادن روتر، پرینتر، سرور و یا سوییچ، فرایند ثبت درخواست تامین، تایید و خرید یک تجهیز جایگزین منجر به وقوع این اختلال بلندمدت می‌شود. داشتن تجهیزات پشتیبان اگرچه در ابتدا هزینه‌ای روی دست سازمان می‌گذارد اما این رقم در قیاس با توقف سرویس ناچیزست. داشتن تجهیزات بکاپ، به میزان قابل‌توجهی می‌تواند نرخ بازگشت‌پذیری سرمایه، اعتماد مشتریان و همچنین نرخ دردسترس پذیری سرویس را به شدت افزایش دهد.
اگر سرویس‌های آنلاین و یا حیاتی سازمانی دارید، همیشه تجهیزات بکاپ در آستین سازمان داشته باشید!
www.MedaNet.ir
تولید ارزش!
لابد این جمله را شنیده‌اید که: "خدا خیرش بده کسی که به من آموخت چطور کامپیوترم رو مجدد راه‌اندازی کنم صدها مشکل آینده‌ی منو حل کرد!" در این نوع ارزش‌گذاری هدف این نیست که چرا مشکل پیش‌آمده و چگونه حل شده؛ بلکه هدف، آموزش راه‌اندازی مجدد کامپیوتر به کاربر است! بنابراین با افزایش سطح آموزش و راهکارهای آموزش تعاملی و کاربردی می‌توانید ارزش مثبت تولید کنید.
وقتی از خلق ارزش توسط یک ارایه‌دهنده‌ی سرویس سخنی به میان می‌آید باید دانست که ارزش به دو روش تولید می‌شود:
1. تولید ارزش مثبت
2. کاهش ارزش منفی
ارزش مثبت، همان پویایی سازمان است سطحی از تجربه‌ی خوب در دریافت خدمات جدید و راهکارهای کارآمد. به‌عنوان‌مثال سرویس‌دهنده می‌تواند مشتری را به یک راه بهتر برای انجام یک کار هدایت کند که سبب می‌شود تا مشتری کارآمدتر باشد. یعنی در این حالت تلاش بر این است که ارزش‌افزوده بیشتر و خدمات بهتر را به مشتری ارائه نمود. این یعنی تولید ارزش مثبت! تولید ارزش مثبت معمولاً: ارائه‌ی خدمات نوین، درک نیازمندی‌های مشتری پیش از طرح موضوع، آموزش و... می‌تواند باشد
اگرچه احتمالاً به‌طور کامل اندازه‌گیری تولید ارزش مثبت غیرممکن است اما در هرحال این موضوع زمانی شدنی است که مهم‌ترین ابزار معیارسنجی و ارزش‌گذاری یا همان سرویس دسک وجود داشته باشد.
×××
و ارزش منفی به میزان بازخوردهای انتقادی به شیوه‌ی عملکرد ارایه‌ی خدمت برمي گردد. بسیاری از تکنسین‌ها و مدیران ارایه‌ی خدمت بر این باورند که برای افزایش سطح رضایتمندی باید کاری کرد که تعداد درخواست‌های مشتریان افزایش بابد این‌گونه هم حجم عملیات ارایه‌ی خدمت به آنان بیشتر به چشم می آید و هم میزان زمان رسیدگی به مشتریان! اما این باور نادرست است؛ زیرا هرچقدر بروکراسی ایجاد کنید و برای یک نیازمندی ساده فردی مجبور به ثبت چندین درخواست شود عملا ارزش منفی خلق می‌کنید.
در حالی‌که با کاهش حجم درخواست‌های کاربران قادر به ذخیره‌ی بیشتر زمان و انرژی تکنسین‌ها و مشتریان می‌شوید علاوه بر آن سبب کاهش نارضایتی و بازخوردهای منفی که همان کاهش ارزش منفی است هم خواهید شد. به‌عنوان‌مثال کاهش نرخ خرابی تجهیزات و یا زمان تعمیرات سرویس و یا زمان رسیدگی به درخواست‌ها!
نکته‌ای که حایز اهمیت است این است که کاهش ارزش منفی، خودش نوعی تولید ارزش مثبت است!
www.MedaNet.ir
لابد این جمله را شنیده‌اید که: "خدا خیرش بده کسی که به من آموخت چطور کامپیوترم رو مجدد راه‌اندازی کنم صدها مشکل آینده‌ی منو حل کرد!" در این نوع ارزش‌گذاری هدف این نیست که چرا مشکل پیش‌آمده و چگونه حل شده؛ بلکه هدف، آموزش راه‌اندازی مجدد کامپیوتر به کاربر است! بنابراین با افزایش سطح آموزش و راهکارهای آموزش تعاملی و کاربردی می‌توانید ارزش مثبت تولید کنید.
وقتی از خلق ارزش توسط یک ارایه‌دهنده‌ی سرویس سخنی به میان می‌آید باید دانست که ارزش به دو روش تولید می‌شود:
1. تولید ارزش مثبت
2. کاهش ارزش منفی
ارزش مثبت، همان پویایی سازمان است سطحی از تجربه‌ی خوب در دریافت خدمات جدید و راهکارهای کارآمد. به‌عنوان‌مثال سرویس‌دهنده می‌تواند مشتری را به یک راه بهتر برای انجام یک کار هدایت کند که سبب می‌شود تا مشتری کارآمدتر باشد. یعنی در این حالت تلاش بر این است که ارزش‌افزوده بیشتر و خدمات بهتر را به مشتری ارائه نمود. این یعنی تولید ارزش مثبت! تولید ارزش مثبت معمولاً: ارائه‌ی خدمات نوین، درک نیازمندی‌های مشتری پیش از طرح موضوع، آموزش و... می‌تواند باشد
اگرچه احتمالاً به‌طور کامل اندازه‌گیری تولید ارزش مثبت غیرممکن است اما در هرحال این موضوع زمانی شدنی است که مهم‌ترین ابزار معیارسنجی و ارزش‌گذاری یا همان سرویس دسک وجود داشته باشد.
×××
و ارزش منفی به میزان بازخوردهای انتقادی به شیوه‌ی عملکرد ارایه‌ی خدمت برمي گردد. بسیاری از تکنسین‌ها و مدیران ارایه‌ی خدمت بر این باورند که برای افزایش سطح رضایتمندی باید کاری کرد که تعداد درخواست‌های مشتریان افزایش بابد این‌گونه هم حجم عملیات ارایه‌ی خدمت به آنان بیشتر به چشم می آید و هم میزان زمان رسیدگی به مشتریان! اما این باور نادرست است؛ زیرا هرچقدر بروکراسی ایجاد کنید و برای یک نیازمندی ساده فردی مجبور به ثبت چندین درخواست شود عملا ارزش منفی خلق می‌کنید.
در حالی‌که با کاهش حجم درخواست‌های کاربران قادر به ذخیره‌ی بیشتر زمان و انرژی تکنسین‌ها و مشتریان می‌شوید علاوه بر آن سبب کاهش نارضایتی و بازخوردهای منفی که همان کاهش ارزش منفی است هم خواهید شد. به‌عنوان‌مثال کاهش نرخ خرابی تجهیزات و یا زمان تعمیرات سرویس و یا زمان رسیدگی به درخواست‌ها!
نکته‌ای که حایز اهمیت است این است که کاهش ارزش منفی، خودش نوعی تولید ارزش مثبت است!
www.MedaNet.ir
راستی را بیازما!
راستی‌آزمایی شاخص‌ها و معیارهای تعریف شده در ابزارهای ITIL کمک می‌کند داده‌های درستی داشته باشید از خاطر نبرید که هدف غایی این چارچوب، بهبودمستمر است ازاین‌رو اگر ممیزی و نظارت خوبی بر داده‌هایی که توسط کاربران و کارشناسان در ابزار قید می‌شود نداشته باشید با داده‌ی زائد یا Garbage Data مواجهه می‌شوید که فقط به درد سطل زباله می‌خورد.
برای نظارت کافیست از نتایج آنچه درج شده گزارشاتی در داشبوردهای متناظر ایجاد نمایید و در عمل هم بررسی کنید.
شوربختانه بسیاری از کارشناسان برای افزایش سطح معیارهای تعیین شده به دنبال تولید اطلاعات نادرستند. مثلاً باید فرق باشد بین درخواستی که توسط کاربر ثبت شده یا کارشناس دارد از طرف کاربر ثبت می‌کند. بعبارتی Created By یک درخواست در درجه‌ی اول باید از سوی کاربر باشد نه از سوی کارشناس. اگر قرارست کارشناسی چیزی از طرفی کسی مطرح کند باید او را Behalf of بگذارد یعنی در اصل درخواست‌کننده خودش هست اما از طرف کسی آنرا قید کرده.
همچنین مدت زمان رسیدگی به درخواست، ثبت گزارشکار Worklog و بررسی صحت اولین واکنش یا FCR- First Call Response کمک می‌کند دقیقاً از نتایج گزارشات، آسوده‌خاطر باشید.
علاوه بر اینها شاخص میزان مسئولیت‌پذیری را می‌توانید با تعداد دفعات پاسکاری درخواست‌ها یا Reassign کردن آنان کنترل کنید.
کنترل نحوه‌ی تکمیل درست فیلدهای یک درخواست نیز می‌تواند معیار باشد. برای اینکار گزارشاتی را بصورت TOP 10 از بین تمام فرایندها و فرم‌ها اخذ کنید و در بازه‌های زمانی مطمئن شوید که آنچه تکمیل شده با آن کاری که واقعاً انجام شده یکی است!
www.MedaNet.ir
راستی‌آزمایی شاخص‌ها و معیارهای تعریف شده در ابزارهای ITIL کمک می‌کند داده‌های درستی داشته باشید از خاطر نبرید که هدف غایی این چارچوب، بهبودمستمر است ازاین‌رو اگر ممیزی و نظارت خوبی بر داده‌هایی که توسط کاربران و کارشناسان در ابزار قید می‌شود نداشته باشید با داده‌ی زائد یا Garbage Data مواجهه می‌شوید که فقط به درد سطل زباله می‌خورد.
برای نظارت کافیست از نتایج آنچه درج شده گزارشاتی در داشبوردهای متناظر ایجاد نمایید و در عمل هم بررسی کنید.
شوربختانه بسیاری از کارشناسان برای افزایش سطح معیارهای تعیین شده به دنبال تولید اطلاعات نادرستند. مثلاً باید فرق باشد بین درخواستی که توسط کاربر ثبت شده یا کارشناس دارد از طرف کاربر ثبت می‌کند. بعبارتی Created By یک درخواست در درجه‌ی اول باید از سوی کاربر باشد نه از سوی کارشناس. اگر قرارست کارشناسی چیزی از طرفی کسی مطرح کند باید او را Behalf of بگذارد یعنی در اصل درخواست‌کننده خودش هست اما از طرف کسی آنرا قید کرده.
همچنین مدت زمان رسیدگی به درخواست، ثبت گزارشکار Worklog و بررسی صحت اولین واکنش یا FCR- First Call Response کمک می‌کند دقیقاً از نتایج گزارشات، آسوده‌خاطر باشید.
علاوه بر اینها شاخص میزان مسئولیت‌پذیری را می‌توانید با تعداد دفعات پاسکاری درخواست‌ها یا Reassign کردن آنان کنترل کنید.
کنترل نحوه‌ی تکمیل درست فیلدهای یک درخواست نیز می‌تواند معیار باشد. برای اینکار گزارشاتی را بصورت TOP 10 از بین تمام فرایندها و فرم‌ها اخذ کنید و در بازه‌های زمانی مطمئن شوید که آنچه تکمیل شده با آن کاری که واقعاً انجام شده یکی است!
www.MedaNet.ir
مدیریت دارایی تمام دارایی‌های سازمان!
دارایی‌های فناوری اطلاعات یا IP-Based هستند یا NON-IP .
آن دسته که دارای IP هستند ازطریق پروتکل‌های بسیاری از سراسر شبکه قابل واکشی‌اند. اما دارایی‌های فاقد IP نیازمند درج دستی و یا واکشی از سیستم‌های انبار سازمانی است.
لزوم تجمیع تمام دارایی‌ها در یک مخزن واحد بنام CMDB امکان مدیریت کامل آن را میسر می‌کند. هدف این نیست فقط بدانیم چقدر دارایی داریم بلکه اینکه بدانیم فلان دارایی دست کیست؟ چه مشخصات نرم‌افزاری و سخت‌افزاری دارد، روابط آن دارایی و تاثیرش در سرویس‌های فناوری چگونه است؟ و نرخ خرابی‌ها، درخواست‌ها، تغییرات و مشکلات مطرح شده بر روی این دارایی چه میزان است؟ و هزینه‌ی خرید و سرویس و استهلاک آن به چه صورتی باید باشد همه و همه کمک می‌کند تا نهایت کنترل را بر مدیریت امنیت اطلاعات، مدیریت مالی، مدیریت تامین‌کنندگان و مدیریت درخواست را داشته باشیم.
×××
مدیریت دارایی در ابزارهای ITIL صرفاً مربوط به فناوری اطلاعات نیست.
واحدهای خدماتی بسیاری در سازمان فعالیت میکنند که حسب نوع فعالیت حاوی مجموعه‌ای از دارایی هستند. استفاده از به‌روش‌های فناوری اطلاعات به سایر واحدهای خدماتی نیز کمک می‌کند تا بر اساس آن، آنان نیز نسبت به مدیریت دارایی خود اقدام کنند. مهم نیست کولر و اسپلیت جزو دارایی است یا میز و در و تخته.
بابت همه‌ی اینها پول هزینه شده و همه‌ی اینها مالک دارند، سابقه‌ی خرید دارند و تعیین جانمای قرارگیری آنان اهمیت دارد. و پولی که بابت سرویس و تعمیر و نگهداری آنان دارد هزینه می‌شود باید مدیریت شود.
سازمان‌هایی که به یک ابزار ITIL مجهزند بخوبی قادرند تا برای تمام واحدهای خدماتی خود تمام تمرینات ITIL را پایه‌ریزی کنند.
چارچوب ITIL بیشتر از آن چیزی است که بسیاری تصور میکنند!
www.MedaNet.ir
دارایی‌های فناوری اطلاعات یا IP-Based هستند یا NON-IP .
آن دسته که دارای IP هستند ازطریق پروتکل‌های بسیاری از سراسر شبکه قابل واکشی‌اند. اما دارایی‌های فاقد IP نیازمند درج دستی و یا واکشی از سیستم‌های انبار سازمانی است.
لزوم تجمیع تمام دارایی‌ها در یک مخزن واحد بنام CMDB امکان مدیریت کامل آن را میسر می‌کند. هدف این نیست فقط بدانیم چقدر دارایی داریم بلکه اینکه بدانیم فلان دارایی دست کیست؟ چه مشخصات نرم‌افزاری و سخت‌افزاری دارد، روابط آن دارایی و تاثیرش در سرویس‌های فناوری چگونه است؟ و نرخ خرابی‌ها، درخواست‌ها، تغییرات و مشکلات مطرح شده بر روی این دارایی چه میزان است؟ و هزینه‌ی خرید و سرویس و استهلاک آن به چه صورتی باید باشد همه و همه کمک می‌کند تا نهایت کنترل را بر مدیریت امنیت اطلاعات، مدیریت مالی، مدیریت تامین‌کنندگان و مدیریت درخواست را داشته باشیم.
×××
مدیریت دارایی در ابزارهای ITIL صرفاً مربوط به فناوری اطلاعات نیست.
واحدهای خدماتی بسیاری در سازمان فعالیت میکنند که حسب نوع فعالیت حاوی مجموعه‌ای از دارایی هستند. استفاده از به‌روش‌های فناوری اطلاعات به سایر واحدهای خدماتی نیز کمک می‌کند تا بر اساس آن، آنان نیز نسبت به مدیریت دارایی خود اقدام کنند. مهم نیست کولر و اسپلیت جزو دارایی است یا میز و در و تخته.
بابت همه‌ی اینها پول هزینه شده و همه‌ی اینها مالک دارند، سابقه‌ی خرید دارند و تعیین جانمای قرارگیری آنان اهمیت دارد. و پولی که بابت سرویس و تعمیر و نگهداری آنان دارد هزینه می‌شود باید مدیریت شود.
سازمان‌هایی که به یک ابزار ITIL مجهزند بخوبی قادرند تا برای تمام واحدهای خدماتی خود تمام تمرینات ITIL را پایه‌ریزی کنند.
چارچوب ITIL بیشتر از آن چیزی است که بسیاری تصور میکنند!
www.MedaNet.ir
سطوح پشتیبانی در ارائه‌ی خدمات!
یکی از رایج‌ترین پرسش‌ها در ذهن مدیران انفورماتیک، کارشناسان فناوری و مدیران ارائه‌ی خدمت به کاربران یا مشتریان این است که یک ارائه‌دهنده خدمات باید از چه نوع مدل پشتیبانی استفاده کند؟
سطوح بندی خدمات پشتیبانی پاسخ این پرسش است و سطح صفر مهم‌ترین سطح آن.
این سطح در حقیقت مختص کاربران است که به خودشان خدمت میکنند آنهم با استفاده از مدیریت دانشی که شما در اختیار آنها قرار داده‌اید. این سطح قدرتمندترین و کم‌هزینه‌ترین سطح پشتیبانی است و جایگاهی است که کارشناسان قادرند تا به‌صورت کاملاً پیشگیرانه جلوی طرح هر پیشامد و حادثه‌ایی که از قبل برایش راه‌حلی ارائه‌شده را بگیرند. این یعنی آنقدر مدیریت دانش منسجم و فرهنگ‌سازی خوبی انجام‌شده که خود کاربران نسبت به حل مشکلات خود با خودآموزی اقدام می‌کند.
×××
اگرچه در پشت پرده سطح صفر(0) در اصل کلیه کارشناسان پشتیبانی انفورماتیک قرار دارند اما آنها در عمل از ارتباط مستقیم با کاربران به دور هستند و صرفاً با درک نقاط درد، چالش‌ها و مشکلات از ثبت بسیاری از حوادث جلوگیری میکنند و انرژی و تخصص خود را بر روی تولید و عرضه دانش به‌روز و مفید گسیل خواهند داشت. سازمان‌هایی که سطح صفر را تقویت میکنند بی‌شک از پیشروترین سازمانها در ارائه ITIL هستند آنها تفکر و استراتژی بلندمدت را بر تاکتیک‌ها و واکنش‌های منفعلانه! ارجحیت داده‌اند.
معمولاً سطح فرایندهای خود خدمتی خودکار مبتنی بر ماشین و تکنولوژی است یعنی در حین دریافت پشتیبانی، استفاده از انسان، کمتر و یا اصلاً دیده نمی‌شود و کاربر در ارتباط با یک سیستم حرفه‌ای و فناورانه نیازهای خود را بدون آنکه درخواستی ثبت کند، مرتفع می‌کند.
www.MedaNet.ir
یکی از رایج‌ترین پرسش‌ها در ذهن مدیران انفورماتیک، کارشناسان فناوری و مدیران ارائه‌ی خدمت به کاربران یا مشتریان این است که یک ارائه‌دهنده خدمات باید از چه نوع مدل پشتیبانی استفاده کند؟
سطوح بندی خدمات پشتیبانی پاسخ این پرسش است و سطح صفر مهم‌ترین سطح آن.
این سطح در حقیقت مختص کاربران است که به خودشان خدمت میکنند آنهم با استفاده از مدیریت دانشی که شما در اختیار آنها قرار داده‌اید. این سطح قدرتمندترین و کم‌هزینه‌ترین سطح پشتیبانی است و جایگاهی است که کارشناسان قادرند تا به‌صورت کاملاً پیشگیرانه جلوی طرح هر پیشامد و حادثه‌ایی که از قبل برایش راه‌حلی ارائه‌شده را بگیرند. این یعنی آنقدر مدیریت دانش منسجم و فرهنگ‌سازی خوبی انجام‌شده که خود کاربران نسبت به حل مشکلات خود با خودآموزی اقدام می‌کند.
×××
اگرچه در پشت پرده سطح صفر(0) در اصل کلیه کارشناسان پشتیبانی انفورماتیک قرار دارند اما آنها در عمل از ارتباط مستقیم با کاربران به دور هستند و صرفاً با درک نقاط درد، چالش‌ها و مشکلات از ثبت بسیاری از حوادث جلوگیری میکنند و انرژی و تخصص خود را بر روی تولید و عرضه دانش به‌روز و مفید گسیل خواهند داشت. سازمان‌هایی که سطح صفر را تقویت میکنند بی‌شک از پیشروترین سازمانها در ارائه ITIL هستند آنها تفکر و استراتژی بلندمدت را بر تاکتیک‌ها و واکنش‌های منفعلانه! ارجحیت داده‌اند.
معمولاً سطح فرایندهای خود خدمتی خودکار مبتنی بر ماشین و تکنولوژی است یعنی در حین دریافت پشتیبانی، استفاده از انسان، کمتر و یا اصلاً دیده نمی‌شود و کاربر در ارتباط با یک سیستم حرفه‌ای و فناورانه نیازهای خود را بدون آنکه درخواستی ثبت کند، مرتفع می‌کند.
www.MedaNet.ir
چالش کارایی شبکه، فرایندهای سطح سرویس
تداوم کارایی یک شبکه به سلامت تجهیزات آن برمی‌گردد این سلامت در حقیقت نظارت بر معیارهای عملکرد در زیرساختهای فناوری اطلاعات است که خود یک رویکرد سازمان‌یافته را می‌طلبد. مدیریت تعیین فاکتورهایی که باید برای عملکرد مورد بررسی قرار گیرند بسیار حائز اهمیت است و معیارهای عملکردی مانند CPU و استفاده از حافظه، افت انتقال بسته، دما، سرعت فن و غیره باید برای کارآیی عملکرد شبکه مرتبا کنترل شوند. بعد از در نظر گرفتن عواملی نظیر اهمیت پارامتر مانیتورینگ و همچنین حساسیت دستگاه می‌توان به دستگاههای خاص و پارامترهای را اولویت‌بندی نمود.
×××
زیرساخت های فناوری اطلاعات فقط به همان اندازه کارآمد است که توانایی ارائه راه‌حل‌های تجاری را دارد. جدا از در دسترس بودن دستگاه ،در دسترس بودن سرویس یا فرآیند نیز نقش بزرگی ایفا می‌کند. اگر یک سرویس یا فرآیند متوقف شود، می‌تواند به طور مستقیم یا غیرمستقیم روی کسب و کار سازمان تأثیر بگذارد، و در نتیجه کسب و کار به شدت متضرر خواهد شد. به همین دلیل، علاوه بر عملکرد دستگاه، باید نظارت بر فرایندها و خدمات مختلفی که در دستگاههای شما اجرا شود که از اهمیت یکسانی برخوردار باشند.
www.MedaNet.ir
تداوم کارایی یک شبکه به سلامت تجهیزات آن برمی‌گردد این سلامت در حقیقت نظارت بر معیارهای عملکرد در زیرساختهای فناوری اطلاعات است که خود یک رویکرد سازمان‌یافته را می‌طلبد. مدیریت تعیین فاکتورهایی که باید برای عملکرد مورد بررسی قرار گیرند بسیار حائز اهمیت است و معیارهای عملکردی مانند CPU و استفاده از حافظه، افت انتقال بسته، دما، سرعت فن و غیره باید برای کارآیی عملکرد شبکه مرتبا کنترل شوند. بعد از در نظر گرفتن عواملی نظیر اهمیت پارامتر مانیتورینگ و همچنین حساسیت دستگاه می‌توان به دستگاههای خاص و پارامترهای را اولویت‌بندی نمود.
×××
زیرساخت های فناوری اطلاعات فقط به همان اندازه کارآمد است که توانایی ارائه راه‌حل‌های تجاری را دارد. جدا از در دسترس بودن دستگاه ،در دسترس بودن سرویس یا فرآیند نیز نقش بزرگی ایفا می‌کند. اگر یک سرویس یا فرآیند متوقف شود، می‌تواند به طور مستقیم یا غیرمستقیم روی کسب و کار سازمان تأثیر بگذارد، و در نتیجه کسب و کار به شدت متضرر خواهد شد. به همین دلیل، علاوه بر عملکرد دستگاه، باید نظارت بر فرایندها و خدمات مختلفی که در دستگاههای شما اجرا شود که از اهمیت یکسانی برخوردار باشند.
www.MedaNet.ir
Forwarded from [ M e d a n e t ]
سرویس دسک چیه.pdf
528.5 KB
احمق با یک ابزار، هنوز احمق است!
این جمله‌ی معروف "گریدی بوچ" مهندس نرم‌افزار آمریکایی است، بوچ به خاطر فعالیت بر روی زبان مدل‌سازی یکپارچه معروف است. وی همچنین در عرصه‌ی بین‌المللی به خاطر کارهای نوآورانه‌اش در معماری نرم‌افزار، مهندسی نرم‌افزار و محیط توسعه‌ی مشارکتی چهره‌ای شناخته‌شده است.
بوچ یک روش توسعه‌ی نرم‌افزاری به نام روش بوچ ایجاد کرد که در کتاب طراحی و آنالیز شی‌گرا خود معرفی کرد. او برای ساده کردن کدها، اضافه نمودن کلاس‌ها را توصیه نمود. روش بوچ روشی است که در مهندسی نرم‌افزار استفاده می‌شود. این روش یک زبان مدل‌سازی شی و اسلوب‌شناسی است که به‌وفور در طراحی و آنالیز شی‌گرا استفاده شده‌است؛ اما قصدم تعریف روش بوچ نیست بلکه پرداختن به جمله‌ی بسیار زیبای اوست که گفت:"احمق با یک ابزار، هنوز احمق است".
×××
اگرچه این عبارت یک امر مطلق نیست اما شکی نیست که یک ابزار هرقدر هم تمام و کمال باشد باز برای کسی که نادان است ابزار کارآمدی نخواهد بود و مصداق همین عبارت یک احمق با یک ابزار هنوز هم احمق است را تداعی می‌کند. این موضوع به نیت تخریب کسی و یا اسائه ادب نیست! بلکه صرفاً یک نکته‌ی بسیار کلیدی در ارتباط با فناوری و زندگی حرفه‌ای ما در سازمان است! هر فنّاوری نوینی و هر راهکار هوشمندی، شبیه یک چاقوی کارآمد و برنده، نیازمند همراهی تفکر و شعور سازمانی است اگر نباشد با دسته‌ی چاقو، دست خود را هم خواهند برید.
×××
اما این عبارت در حوزه فناوری و بخصوص در کلیه سازمانها چه مفهومی دارد؟
هر نرم‌افزاری که در سازمان شما پیاده‌سازی می‌شود باید یک فرآیند کسب‌وکار را فعال کند و یا بهبود دهد. متأسفانه بسیاری از مردم به‌اشتباه بر این باورند که نرم‌افزار و یا فن‌آوری، به‌خودی‌خود، تماماً راه‌حل است، درحالی‌که درواقع، فنّاوری در بهترین حالت ۱۰ درصد از ارزش این معادله است و ۹۰ درصد دیگر بر اساس عامل انسانی و فرهنگ بکارگیری مقوله‌ی تحول دیجیتال است. ابزار کارآمد صرفاً سهولت را به همراه دارد اما باید پذیرفت که بدون داشتن چارچوب استفاده و پیاده‌سازی، سهم فناوری خیلی ناچیز است.
در هنگام انتخاب ابزار ITIL نیز این موضوع صدق می‌کند. سازمانها به‌محض خرید یا داشتن نرم‌افزار مربوطه، فکر میکنند عصای حضرت موسی است و با آن انقلابی رخ خواهد داد. درحالی‌که تا فرهنگ ITIL جا نیفتد تا شعور سازمانی استفاده از آن وجود نداشته باشد هر ابزاری، فقط هزینه‌ی اضافه است!
این را به تمام ابزارهای زندگی و کسب‌وکار تعمیم دهید نتیجه همین است!
www.MedaNet.ir
این جمله‌ی معروف "گریدی بوچ" مهندس نرم‌افزار آمریکایی است، بوچ به خاطر فعالیت بر روی زبان مدل‌سازی یکپارچه معروف است. وی همچنین در عرصه‌ی بین‌المللی به خاطر کارهای نوآورانه‌اش در معماری نرم‌افزار، مهندسی نرم‌افزار و محیط توسعه‌ی مشارکتی چهره‌ای شناخته‌شده است.
بوچ یک روش توسعه‌ی نرم‌افزاری به نام روش بوچ ایجاد کرد که در کتاب طراحی و آنالیز شی‌گرا خود معرفی کرد. او برای ساده کردن کدها، اضافه نمودن کلاس‌ها را توصیه نمود. روش بوچ روشی است که در مهندسی نرم‌افزار استفاده می‌شود. این روش یک زبان مدل‌سازی شی و اسلوب‌شناسی است که به‌وفور در طراحی و آنالیز شی‌گرا استفاده شده‌است؛ اما قصدم تعریف روش بوچ نیست بلکه پرداختن به جمله‌ی بسیار زیبای اوست که گفت:"احمق با یک ابزار، هنوز احمق است".
×××
اگرچه این عبارت یک امر مطلق نیست اما شکی نیست که یک ابزار هرقدر هم تمام و کمال باشد باز برای کسی که نادان است ابزار کارآمدی نخواهد بود و مصداق همین عبارت یک احمق با یک ابزار هنوز هم احمق است را تداعی می‌کند. این موضوع به نیت تخریب کسی و یا اسائه ادب نیست! بلکه صرفاً یک نکته‌ی بسیار کلیدی در ارتباط با فناوری و زندگی حرفه‌ای ما در سازمان است! هر فنّاوری نوینی و هر راهکار هوشمندی، شبیه یک چاقوی کارآمد و برنده، نیازمند همراهی تفکر و شعور سازمانی است اگر نباشد با دسته‌ی چاقو، دست خود را هم خواهند برید.
×××
اما این عبارت در حوزه فناوری و بخصوص در کلیه سازمانها چه مفهومی دارد؟
هر نرم‌افزاری که در سازمان شما پیاده‌سازی می‌شود باید یک فرآیند کسب‌وکار را فعال کند و یا بهبود دهد. متأسفانه بسیاری از مردم به‌اشتباه بر این باورند که نرم‌افزار و یا فن‌آوری، به‌خودی‌خود، تماماً راه‌حل است، درحالی‌که درواقع، فنّاوری در بهترین حالت ۱۰ درصد از ارزش این معادله است و ۹۰ درصد دیگر بر اساس عامل انسانی و فرهنگ بکارگیری مقوله‌ی تحول دیجیتال است. ابزار کارآمد صرفاً سهولت را به همراه دارد اما باید پذیرفت که بدون داشتن چارچوب استفاده و پیاده‌سازی، سهم فناوری خیلی ناچیز است.
در هنگام انتخاب ابزار ITIL نیز این موضوع صدق می‌کند. سازمانها به‌محض خرید یا داشتن نرم‌افزار مربوطه، فکر میکنند عصای حضرت موسی است و با آن انقلابی رخ خواهد داد. درحالی‌که تا فرهنگ ITIL جا نیفتد تا شعور سازمانی استفاده از آن وجود نداشته باشد هر ابزاری، فقط هزینه‌ی اضافه است!
این را به تمام ابزارهای زندگی و کسب‌وکار تعمیم دهید نتیجه همین است!
www.MedaNet.ir
با خودکارسازی، جلوی دخالت انسانی را بگیرید!
اصل هفتم از ITIL نسخه ۴، تاکید فراوانی بر بهینه‌سازی و خودکارسازی کرده، به‌‌عبارتی فرایندها باید به شکلی پیاده‌سازی شده باشند که بعد از استقرار، کمترین مداخله‌ی انسانی را به همراه داشته باشد مگر در جایی که مداخله‌ی او منجر به خلق ارزش شود. این یعنی سرویس، باید آنقدر خوب پیاده‌سازی شده باشد و آنقدر از نگاه مشتری و یا کاربر به مسائل نگریسته شده باشد که از این به بعد، ربات‌ها و انجین‌ها دنباله‌رو کار باشند.
هوش مصنوعی AI، ابزارهای هوش تجاری BI و.. در بسیاری از تجهیزات و فناوری‌های سخت‌افزاری و نرم‌افزاری امروزه به وفور در دسترس است اما همچنان شاهد حضور پر رنگ نیروهایی هستیم که تمایلی به این فناوری‌ها ندارند. از این‌رو مداخلات انسانی بطور چشمگیری همچنان هست بی‌آنکه ارزشی خلق کنند.
×××
خودکارسازی به معنی اتوماسیون اداری نیست! اینکه فقط چند فرم و فرایند کاغذی را مبدل به فرم‌های دیجیتالی کنیم کار شاقی نکردیم! زیرا همه‌ی آن آدم‌هایی که تا دیروز کاغذ دست می‌گرفتند حضور دارند فقط بجای کاغذ، فرم نرم‌افزاری در دست دارند! و این یعنی BAU کسب‌وکار به شکل مرسوم!
با شناسایی رویه‌های پرتکرار و مواردی که سیستم می‌تواند بجای انسان عملکرد بهتری داشته باشد می‌توان برایشان راهکارهای بهبود و خودکارسازی را طراحی و اجرا کرد تا نه تنها شکل ظاهری کار بلکه شکل باطنی نیز تغییر کند با این هدف که سرویس بهتر، سریع‌تر و البته با کمترین نرخ مداخله‌ی انسانی ارایه نمود.
ربات تکنسین در ابزارهای پیاده‌سازی ITIL، توزیع پالیسی در ابزارهای اکتیودایرکتوری و Spanning Tree در پیکربندی و مسیریابی روتر و سوییچ نمونه‌ای از این روش‌های خودکارسازی است.
www.MedaNet.ir
اصل هفتم از ITIL نسخه ۴، تاکید فراوانی بر بهینه‌سازی و خودکارسازی کرده، به‌‌عبارتی فرایندها باید به شکلی پیاده‌سازی شده باشند که بعد از استقرار، کمترین مداخله‌ی انسانی را به همراه داشته باشد مگر در جایی که مداخله‌ی او منجر به خلق ارزش شود. این یعنی سرویس، باید آنقدر خوب پیاده‌سازی شده باشد و آنقدر از نگاه مشتری و یا کاربر به مسائل نگریسته شده باشد که از این به بعد، ربات‌ها و انجین‌ها دنباله‌رو کار باشند.
هوش مصنوعی AI، ابزارهای هوش تجاری BI و.. در بسیاری از تجهیزات و فناوری‌های سخت‌افزاری و نرم‌افزاری امروزه به وفور در دسترس است اما همچنان شاهد حضور پر رنگ نیروهایی هستیم که تمایلی به این فناوری‌ها ندارند. از این‌رو مداخلات انسانی بطور چشمگیری همچنان هست بی‌آنکه ارزشی خلق کنند.
×××
خودکارسازی به معنی اتوماسیون اداری نیست! اینکه فقط چند فرم و فرایند کاغذی را مبدل به فرم‌های دیجیتالی کنیم کار شاقی نکردیم! زیرا همه‌ی آن آدم‌هایی که تا دیروز کاغذ دست می‌گرفتند حضور دارند فقط بجای کاغذ، فرم نرم‌افزاری در دست دارند! و این یعنی BAU کسب‌وکار به شکل مرسوم!
با شناسایی رویه‌های پرتکرار و مواردی که سیستم می‌تواند بجای انسان عملکرد بهتری داشته باشد می‌توان برایشان راهکارهای بهبود و خودکارسازی را طراحی و اجرا کرد تا نه تنها شکل ظاهری کار بلکه شکل باطنی نیز تغییر کند با این هدف که سرویس بهتر، سریع‌تر و البته با کمترین نرخ مداخله‌ی انسانی ارایه نمود.
ربات تکنسین در ابزارهای پیاده‌سازی ITIL، توزیع پالیسی در ابزارهای اکتیودایرکتوری و Spanning Tree در پیکربندی و مسیریابی روتر و سوییچ نمونه‌ای از این روش‌های خودکارسازی است.
www.MedaNet.ir
تغییر ناآگاه، رنج است!
چه در زندگی شخصی و چه در محیط کسب و کار، همواره ما با مفهوم تغییر بارها سر و کله زده‌ایم. بنابراین چیز جدیدی نیست که از عنوان آن تماماً بی‌اطلاع باشیم. اساس تغییر برای رشد و بهبود است! بنابراین ما تغییر می‌کنیم چون می‌خواهیم رشد کنیم. بسیاری از این تغییرات برای بهتر شدن و بسیاری هم برای همسو شدن با دیگران و اغلب غافل نماندن از قافله است. اگر یک فعال و ارایه‌ی دهنده یک خدمت هستید حال چه آن خدمت از جنس فناوری اطلاعات باشد و یا هر خدمتی دیگر، خیلی خوب می‌دانید که هر روز با طیف وسیعی از تغییرات مواجه هستیم. بسیاری از این تغییرات مجموعه اقدامات فوری‌اند و برخی حیاتی و برخی تصمیمات ناآگاهانه‌ای است که اجرای آن باید در جایی ثبت و ضبط گردد، تا نتیجه‌ی آن، درس عبرتی برای عدم تکرار در آینده باشد.
×××
تغییر کردن و تغییر دادن به معنای مدیریت کردن آن نیست! تغییر را اگر نتوان کنترل و هدایت کرد مبدل به یک تصمیم نادرست می‌شود که شانس موفقیت‌آمیز بودن آن به‌شدت کاهش خواهد یافت. بنابراین برای کنترل هر تغییری به مفهومی بنام مدیریت تغییر نیاز داریم، زیرا بدون مدیریت، هر تغییری ممکن است خطرات زیان‌بار و بی‌بازگشتی را رقم بزند و زندگی یا کسب و کار ما را متأثر از خود کند که در آن‌صورت خواهیم گفت:"کاش این تغییر را انجام نمی‌دادیم!" نمونه‌های بی‌شماری از این دست تغییرات در سراسر پیرامون زندگی شخصی و کاری ما هست که خودتان بهتر به آنها واقفید.
پس با داشتن مدیریت تغییر، سعی می‌کنیم قبل از انجام هر کاری، تحلیل درستی را انجام دهیم، خطرات آن را ارزیابی کنیم و میزان اثربخشی آن تغییر را بتوانیم اندازه‌گیری کنیم تا تغییری موفق و آگاهانه محسوب شود. اگر با این نگاه به مسائل دید بیندازید حرفه‌ای‌تر از دیگران پیش خواهید رفت!
فراموش نکنید تغییری که ارزیابی نشده و ریسک آن اندازه‌گیری نشده، یک تصمیم غلط و البته گاهی رنجی تلخ و بی‌پایان است!
www.MedaNet.ir
چه در زندگی شخصی و چه در محیط کسب و کار، همواره ما با مفهوم تغییر بارها سر و کله زده‌ایم. بنابراین چیز جدیدی نیست که از عنوان آن تماماً بی‌اطلاع باشیم. اساس تغییر برای رشد و بهبود است! بنابراین ما تغییر می‌کنیم چون می‌خواهیم رشد کنیم. بسیاری از این تغییرات برای بهتر شدن و بسیاری هم برای همسو شدن با دیگران و اغلب غافل نماندن از قافله است. اگر یک فعال و ارایه‌ی دهنده یک خدمت هستید حال چه آن خدمت از جنس فناوری اطلاعات باشد و یا هر خدمتی دیگر، خیلی خوب می‌دانید که هر روز با طیف وسیعی از تغییرات مواجه هستیم. بسیاری از این تغییرات مجموعه اقدامات فوری‌اند و برخی حیاتی و برخی تصمیمات ناآگاهانه‌ای است که اجرای آن باید در جایی ثبت و ضبط گردد، تا نتیجه‌ی آن، درس عبرتی برای عدم تکرار در آینده باشد.
×××
تغییر کردن و تغییر دادن به معنای مدیریت کردن آن نیست! تغییر را اگر نتوان کنترل و هدایت کرد مبدل به یک تصمیم نادرست می‌شود که شانس موفقیت‌آمیز بودن آن به‌شدت کاهش خواهد یافت. بنابراین برای کنترل هر تغییری به مفهومی بنام مدیریت تغییر نیاز داریم، زیرا بدون مدیریت، هر تغییری ممکن است خطرات زیان‌بار و بی‌بازگشتی را رقم بزند و زندگی یا کسب و کار ما را متأثر از خود کند که در آن‌صورت خواهیم گفت:"کاش این تغییر را انجام نمی‌دادیم!" نمونه‌های بی‌شماری از این دست تغییرات در سراسر پیرامون زندگی شخصی و کاری ما هست که خودتان بهتر به آنها واقفید.
پس با داشتن مدیریت تغییر، سعی می‌کنیم قبل از انجام هر کاری، تحلیل درستی را انجام دهیم، خطرات آن را ارزیابی کنیم و میزان اثربخشی آن تغییر را بتوانیم اندازه‌گیری کنیم تا تغییری موفق و آگاهانه محسوب شود. اگر با این نگاه به مسائل دید بیندازید حرفه‌ای‌تر از دیگران پیش خواهید رفت!
فراموش نکنید تغییری که ارزیابی نشده و ریسک آن اندازه‌گیری نشده، یک تصمیم غلط و البته گاهی رنجی تلخ و بی‌پایان است!
www.MedaNet.ir
عجله یا Agile؟
امروزه روی کوچک‌سازی و چابک سازی کسب‌وکارها خیلی تأکید می‌شود حتی برای توسعه‌ی پروژه‌ها و نرم‌افزارها نیز اصول و شیوه‌های چابک سازی ارائه‌شده. ریشه‌ی کلمه‌ی Agile که یک واژه‌ی هندواروپایی است بعدها در لفظ لاتین قرن شانزدهم به معنای انجام دادن مطرح شد که خود از Agilis به معنای زیبا و سریع و از Agere به معنای راندن، بیرون کشیدن یا پیش بردن و حرکت دادن نشأت گرفته و امروزه این صفت یعنی چابک و سریع. به نظرم لغت Agile (اجایل) با لغت عجله بی‌ارتباط نیست! بخصوص آنکه بسیاری از برنامه‌نویسان علیرغم وجود این چارچوب به همان روال مرسوم و سنتی خود عمل میکنند و در بهترین حالت فقط سریع‌ترند!
×××
فارغ از ریشه‌ی این صفت پرکار، اکثر سازمانها به‌ویژه سازمان‌های داخل کشور به همان کلمه‌ی چابک یا عجله بسنده میکنند بی‌آنکه سراغ انطباق نرم‌افزار و اصول توسعه‌ی آن باشند. بسیاری از توسعه‌دهندگان نرم‌افزار به دنبال شتاب دادن تولید محصول‌اند درحالی‌که سرعت، نرخ خطا را نیز افزایش خواهد داد. اگر همراه با سرعت، روی سایر اصول تمرکز نشوند فرقی با استفاده نکردن از Agile ندارند. همکاری گسترده، توسعه‌ی پایدار، سادگی، استقبال از تغییرات و ... جزو ارکان کلیدی این چارچوب توسعه است.
×××
اگرچه Agile با ITIL میانه‌ی خوبی ندارد که البته این همان نگاه سنتی و تضاد فکری برنامه‌نویسان با کارشناسان شبکه و پشتیبانی است که سبب بروز این رابطه‌ی ناخوشایند شده، اما اگر نگاه سازمان بر پایه‌ی خلق ارزش باشد ادغام این دو چارچوب ممکن می‌شود و حتی در جای‌جایی قادرند تا به‌خوبی همدیگر را هم‌پوشانی کنند و نقاط ضعف هم را پوشش دهند. ولی بد نیست بدانید ازآنجایی‌که دنیا به سمت As Service رفته پس هر محصولی چه نرم‌افزاری باشد چه سخت‌افزاری یک سرویس یا خدمت است و چه چارچوبی بهتر از ITIL برای مدیریت خدمت!؟
www.MedaNet.ir
امروزه روی کوچک‌سازی و چابک سازی کسب‌وکارها خیلی تأکید می‌شود حتی برای توسعه‌ی پروژه‌ها و نرم‌افزارها نیز اصول و شیوه‌های چابک سازی ارائه‌شده. ریشه‌ی کلمه‌ی Agile که یک واژه‌ی هندواروپایی است بعدها در لفظ لاتین قرن شانزدهم به معنای انجام دادن مطرح شد که خود از Agilis به معنای زیبا و سریع و از Agere به معنای راندن، بیرون کشیدن یا پیش بردن و حرکت دادن نشأت گرفته و امروزه این صفت یعنی چابک و سریع. به نظرم لغت Agile (اجایل) با لغت عجله بی‌ارتباط نیست! بخصوص آنکه بسیاری از برنامه‌نویسان علیرغم وجود این چارچوب به همان روال مرسوم و سنتی خود عمل میکنند و در بهترین حالت فقط سریع‌ترند!
×××
فارغ از ریشه‌ی این صفت پرکار، اکثر سازمانها به‌ویژه سازمان‌های داخل کشور به همان کلمه‌ی چابک یا عجله بسنده میکنند بی‌آنکه سراغ انطباق نرم‌افزار و اصول توسعه‌ی آن باشند. بسیاری از توسعه‌دهندگان نرم‌افزار به دنبال شتاب دادن تولید محصول‌اند درحالی‌که سرعت، نرخ خطا را نیز افزایش خواهد داد. اگر همراه با سرعت، روی سایر اصول تمرکز نشوند فرقی با استفاده نکردن از Agile ندارند. همکاری گسترده، توسعه‌ی پایدار، سادگی، استقبال از تغییرات و ... جزو ارکان کلیدی این چارچوب توسعه است.
×××
اگرچه Agile با ITIL میانه‌ی خوبی ندارد که البته این همان نگاه سنتی و تضاد فکری برنامه‌نویسان با کارشناسان شبکه و پشتیبانی است که سبب بروز این رابطه‌ی ناخوشایند شده، اما اگر نگاه سازمان بر پایه‌ی خلق ارزش باشد ادغام این دو چارچوب ممکن می‌شود و حتی در جای‌جایی قادرند تا به‌خوبی همدیگر را هم‌پوشانی کنند و نقاط ضعف هم را پوشش دهند. ولی بد نیست بدانید ازآنجایی‌که دنیا به سمت As Service رفته پس هر محصولی چه نرم‌افزاری باشد چه سخت‌افزاری یک سرویس یا خدمت است و چه چارچوبی بهتر از ITIL برای مدیریت خدمت!؟
www.MedaNet.ir
آیا زمان آن فرا رسیده که از مدیریت خدمات استفاده کنید؟
هشت نشانه که هنگام استفاده از مدیریت خدمات در سازمان شما فرا رسیده...
از لینک زیر بخوانید
https://lnkd.in/eBguPCna
هشت نشانه که هنگام استفاده از مدیریت خدمات در سازمان شما فرا رسیده...
از لینک زیر بخوانید
https://lnkd.in/eBguPCna
قلم پیکربندی چیست و چگونگی کشف آن در ITIL
بررسی مفصل CI و CM و CMDB
از لینک زیر بخوانید...
https://lnkd.in/eWBh-zxf
بررسی مفصل CI و CM و CMDB
از لینک زیر بخوانید...
https://lnkd.in/eWBh-zxf