حکایت نرم افزارها و سازمانها

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

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

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

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

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