برای ایجاد تغییرات فقط نوشتن یک دستورالعمل کافی نیست

آیا صرفا نوشتن یک دستورالعمل خوب برای تغییر یک موضوع سازمانی (مثلا فرایند ارتباط با مشتری) ما را به نتایج خوبی می رساند؟ آیا تضمین می کند که تغییر با موفقیت انجام شود؟ چند درصد از موفقیت یک تغییر دستورالعملی است که می گوید رویه جدید چگونه باید باشد؟

بیایید تغییر در سازمان را به نصب یک نرم افزار تشبیه کنیم و ببینیم چه چیزهایی از این تشبیه یاد می گیریم که کمک می کند تا تغییرات موفق تری داشته باشیم.

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

انتقال فایل به سرور :دستورالعمل تغییر

اولا بدیهی است که باید فایل نرم افزار وارد محیطی شود که قرار است نصب شود. شما باید آنرا روی کامپیوتر سرور (server) مشتری منتقل کنید و برای این کار نیاز به مجوز و البته پورت ورود اطلاعات دارید. باید به شما اجازه بدهند که نرم افزار بر روی سرور نصب شود.

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

 آنتی ویروس ها :دستورالعمل تغییر

آنتی ویروس هایی که روی سیستم نصب شده است مراقب ورود نرم افزارهای زیان آور و ویروس ها هستند و ممکن است نرم افزار جدید را نیز ویروس تلقی کنند و عملا امکان نصب نرم افزار جدید را صلب کنند لذا باید نرم افزار جدید به آنتی ویروس معرفی شود.

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

۳۲ بیتی یا ۶۴ بیتی، ویندوز یا مک :دستورالعمل تغییر

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

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

ویزارد نصب :دستورالعمل تغییر

نرم افزار هر چقدر هم خوب نوشته شده باشد ولی روشی برای نصب نداشته باشد، نصب نمی شود! حتما باید حداقل یک فایل set up داشته باشد.

دستورالعمل های تغییر باید ضمیمه نحوه اجرا داشته باشند. چطور باید آنرا اجرا کنیم؟ سر خط کجاست، مراحل اجرا چیست؟ مقدمات و ملزومات اجرا چه هستند؟ متولیان اجرا چه آموزشهایی باید ببینند؟ چگونه این آموزشها به آنها منتقل شود؟ چه منابعی باید در اختیار باشد؟ و …

پروتوتایپ :

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

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

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

 

سیستم عامل زندگیتان به روز و برقرار باد 🙂

شما ممکن است این را هم بپسندید

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *