Y@SiN
11-19-2009, 07:25 PM
در نوشته قبلی از سلسه مطالب خدمات پشتیبانی محصول نرم افزاری، به برخی دلایل اهمیت بحث مدیریت بحران در ساختار خدمات پشتیبانی اشاره کرده بودم، آنکه، عمده ترین دلیل بروز بحران،" تغییر" است. تغییراتی که اگر درست شناسایی نشده و یا مدیریت نشوند، باعث بروز بحرانهای جدی شده و مشکلاتی را برای شرکت فراهم سازند. در ادامه به برخی مشکلات، روش شناسایی و حل آن اشاره خواهم کرد: اولین مورد، "تغییر مدیریتی"
هر کدام از مدیران ارشد و میانی مرتبط با نرم افزار که تغییر کنند، می تواند یک بحران جدید برای خدمات پشتیبانی داشته باشد، آنجا که مدیران جدید همه کارهای مدیران قدیمی را نفی می کنند و می خواهند سلیقه خودشان درست یا غلط در نرم افزار ایجاد شود.
- روش شناسایی: اغلب تغییر یک مدیر را پس از عوض شدن وی متوجه می شویم و گاهی مواقع آنقدر دیرهنگام که دیگر فرصتی برای عکس العمل درست نیست. راهکار آن است که به صورت دوره ای با مشتری تماس گرفته شود، داده از پیرامون آن شرکت جمع آوری شود، تغییرات وضع اقتصادی شرکتها مهم شمرده شود، تغییر مدیران ارشد سازمانها و یا دولت مد نظر قرارداده شود و... تا از وضعیت حضور یک مدیر و قدرت و ماندگاری آن مطمئن شویم و یا اگر به هر دلیلی این مدیر تغییر کرد بسیار سریع متوجه شویم.
- مکانیسم برخورد: اگر مدیری تغییر کرد، باید در اولین فرصت ممکن با مدیر جدید ارتباط برقرار کرد،با مدیریت ارتباط بدون آنکه به وی اجازه دهیم، فرصتی برای اعمال سلیقه داشته باشد، انجام کارها به روند جاری مد نظر ما را برایش توجیه کنیم به شکلی که نظر ما را نظر خود بداند، اهمیت سیستم به وی گوشزد شود و اینکه وجود سیستم و کارکردن آن می تواند به وی در انجام کار های جاری بخش تحت نظرش و یا سرویس دهی مورد نظر وی کمک کند.
گاهی اوقات نیز باید به جای توجه به مدیر میانی تغییر یافته، ارتباط خود را با مدیر ارشد و یا مدیران میانی صاحب نفوذ مستحکم تر کرد به شکلی که با تغییر یک مدیر ماهیت نرم افزار زیر سوال نرود.
می توان با گسترش نفوذ در لایه های عملیاتی نیز، چنان سیستم را عملیاتی و فعال نمود که تغییر آن به صلاح هیچ مدیری نباشد.
در یک کلام باید اطلاعات را زودهنگام جمع آوری کرد و به موقع عمل نمود.
همین!
هر کدام از مدیران ارشد و میانی مرتبط با نرم افزار که تغییر کنند، می تواند یک بحران جدید برای خدمات پشتیبانی داشته باشد، آنجا که مدیران جدید همه کارهای مدیران قدیمی را نفی می کنند و می خواهند سلیقه خودشان درست یا غلط در نرم افزار ایجاد شود.
- روش شناسایی: اغلب تغییر یک مدیر را پس از عوض شدن وی متوجه می شویم و گاهی مواقع آنقدر دیرهنگام که دیگر فرصتی برای عکس العمل درست نیست. راهکار آن است که به صورت دوره ای با مشتری تماس گرفته شود، داده از پیرامون آن شرکت جمع آوری شود، تغییرات وضع اقتصادی شرکتها مهم شمرده شود، تغییر مدیران ارشد سازمانها و یا دولت مد نظر قرارداده شود و... تا از وضعیت حضور یک مدیر و قدرت و ماندگاری آن مطمئن شویم و یا اگر به هر دلیلی این مدیر تغییر کرد بسیار سریع متوجه شویم.
- مکانیسم برخورد: اگر مدیری تغییر کرد، باید در اولین فرصت ممکن با مدیر جدید ارتباط برقرار کرد،با مدیریت ارتباط بدون آنکه به وی اجازه دهیم، فرصتی برای اعمال سلیقه داشته باشد، انجام کارها به روند جاری مد نظر ما را برایش توجیه کنیم به شکلی که نظر ما را نظر خود بداند، اهمیت سیستم به وی گوشزد شود و اینکه وجود سیستم و کارکردن آن می تواند به وی در انجام کار های جاری بخش تحت نظرش و یا سرویس دهی مورد نظر وی کمک کند.
گاهی اوقات نیز باید به جای توجه به مدیر میانی تغییر یافته، ارتباط خود را با مدیر ارشد و یا مدیران میانی صاحب نفوذ مستحکم تر کرد به شکلی که با تغییر یک مدیر ماهیت نرم افزار زیر سوال نرود.
می توان با گسترش نفوذ در لایه های عملیاتی نیز، چنان سیستم را عملیاتی و فعال نمود که تغییر آن به صلاح هیچ مدیری نباشد.
در یک کلام باید اطلاعات را زودهنگام جمع آوری کرد و به موقع عمل نمود.
همین!