نرم‌افزارهای یكپارچه قضاوت می‌كنند

تكنولوژی علیه تكنولوژی

تاريخ:3 مهر 1388

ماندانا خرم - وجیهه كردبچه- دنیای كامپیوتر و ارتباطات
در اولین هفته از آخرین ماه تابستان، برخی از مدیران شركت‌های معتبر و نام آشنا اما نگران از وضعیت كنونی ای.آر.پی‌ها در شركت «مدار گسترش فناوری و اطلاعات تهران» دور هم گرد آمدند تا آخرین وضعیت و مشكلات رو به افزایش ای.آر.پی‌ها را به بحث و گفت‌وگو بگذارند.  بهرنگ عاصمی دبیر انجمن ای.آرپی‌های ایران، محمد ظاهری مدیرعامل شركت سندپرداز، امیر رهنمافر مدیرعامل شركت مدار گسترش، پیروز سلطانی مدیرعامل شركت پارس رویال و علیرضا علاوش معاونت پشتیبانی سبز داده‌افزار از حاضرین در این میزگرد بودند.

رقابت نابرابر بین شركت‌های داخلی و خارجی، فقدان سرمایه‌گذاری كلان از سوی شركت‌های دولتی و خصوصی، تعریف نادرست از صنعت نرم‌افزاری یكپارچه، عدم بسترسازی مناسب از سوی متولیان دولتی و در نهایت مشكلات ناشی از حقوق مولف (كپی‌رایت) از جمله عناوین مهم رئوس مطرح شده در این میزگرد بود. این مجموعه كه به تازگی پیشنهاد و درخواست خود را به وزارت علوم تسلیم كردند امیدوارند كه در یكی دو ماه آینده مجوز انجمن ای.آر.پی‌های ایران را از این وزارتخانه دریافت دارند. بدیهی است چنانچه این درخواست از سوی وزارت علوم پذیرفته شود از این پس شركت‌های نرم‌افزاری یكپارچه تریبونی خواهند داشت كه از مجرای آن می توانند صدای خود را به دیگران برسانند.

 بهرنگ عاصمی: موضوع بحث به طور خاص مشكلات تولید و استقرار ERP شركت‌های تولیدكننده ERP عضو انجمن است و طبیعتاً همكاران با بسیاری از این مشكلات به طور مستقیم برخورد كرده‌اند. یكی از موارد مهم در صنعت نرم‌افزارهای ERP و نرم‌افزارهای مشابه آن كه بر اساس نیاز مشتری طراحی می‌شوند موضوع شناخت نیاز مشتری، و انطباق آن با محیط كار است.  از طرفی بسیاری از سازمان‌های ایرانی شاید هنوز به بلوغ سازمانی كافی نرسیده باشند تا بتوانند به درستی نیازهای خود را شناخته و بیان كنند و انتظارات خود را از شركت نرم‌افزاری مطالبه كنند. شما به عنوان یك شركت نرم‌افزاری چگونه سعی می‌كنید نیازهای مشتری خود را شناسایی كنید و در نرم‌افزار اعمال نمایید و در نهایت به مشتری محصولی ارایه كنید تا برطرف‌كننده بخشی از مشكلات وی باشد؟ محمد

ظاهری: عمده فعالیت‌های شركت سندپرداز در مورد ERP است و تمركز آن بر شركت‌های تولیدی است. نباید خدمات ما در حد یك تكنولوژی یا یك برنامه‌نویسی تنزل پیدا كند. درواقع ما باید مجموعه خدمات وسیعی ارایه دهیم كه قسمت كوچكی از آن شناخته شده است. یكی از مهمترین مسایل این است كه بدانیم «چه باید بكنیم؟ و چه مشكلی را حل كنیم؟» اگر خودمان را ارایه دهنده راه‌حل می‌دانیم اولین سئوال این است كه چه مشكلی باید حل شود؟ خود شناخت این مشكل كار ساده‌ای نیست. در یك جامعه توسعه یافته صنعتی، حضور مشاورینی كه مشكلات را شناسایی می‌كنند و RFP دقیق و جامعی ارایه می‌دهند، بسیاری از پیچیدگی‌ها را حل می‌كند. 

این در حالی است كه ما با هیچ RFP صریحی مواجه نیستیم. حتی شركت‌هایی كه به كمك مشاور RFP  تهیه می‌كنند، در بسیاری مواقع در عمل یك كپی‌برداری از مستندات مشابه داخلی یا خارجی انجام می‌دهند كه هیچ نگاه خاصی به مشتری ندارد. پس این موضوع مهمی است كه ما با سازمان‌هایی مواجه هستیم كه مشكل دارند، اما قادر به بیان كردن و حل آن نیستند. درواقع نتایج مورد انتظار از ERP هم مشخص نیست. به عبارتی ما وارد عرصه‌ای می‌شویم كه نقطه‌ای برای مقبولیت آن وجود ندارد و شاید نتوان برای آن نقطه پایانی متصور شد.  شركت‌های نرم‌افزاری نقش چندگانه‌ای در این زمینه بازی می‌كنند. خود ایشان باید مشكل را پیدا كنند، برای آن راه‌حل ارایه دهند و آن را برای كارفرما توجیه كنند. به عبارتی ما در پروژه‌های ERP  با یك مدلی رو به رو هستیم كه كاملاً بر اساس اعتماد شكل می‌گیرد. اگر یك كارفرما یك پیمانكار را انتخاب می‌كند، این كار، عمدتاً بر اساس اعتماد انجام شده نه اینكه بر اساس قوانین یا توان كاری بوده باشد.

این امر، مشكلات زیادی به همراه دارد.  ممكن است در این میان یك سری شاخص دست نیافتنی و كلیشه‌ای مطرح شود. در چنین موقعیتی جلب رضایت كامل كارفرما، تقریباً غیرممكن خواهد بود. من مشكل اصلی كار را این موضوع می‌دانم كه كه مشكل سازمان‌ها به راحتی قابل تشخیص نیست. این موضوع عمدتاً به این دلیل است كه كارفرماها مشاوران خود را به خوبی انتخاب نمی‌كنند. گاهی اوقات حتی صورت مسئله عوض می‌شود. بنابراین شركت‌های نرم‌افزاری، مسئولند كه نیاز را به طور كامل شناسایی كنند و تحلیل كنند و حتی نتایج مورد انتظار را استخراج كنند.  در نهایت می‌توان گفت شركت‌های نرم‌افزاری به نوعی سفارش‌دهنده، تهیه‌كننده و تحویل‌گیرنده راه‌حل خواهند بود. مدیران ما، مدیرانی هستند كه بیشتر علاقه دارند كارها بر اساس اعتماد انجام شود تا بر اساس علم. در نتیجه مسئولیت‌ها مرز مشخصی ندارد. این شركت‌های نرم‌افزاری هستند كه در نهایت مسئول و ضامن انجام كار هستند و نقش چندگانه‌ای ایفا می‌كنند.

در كار ما این مشكل ابعاد عمیق‌تری هم پیدا می‌كند. چون بعد از انقلاب كارگاه‌های كوچك زیادی شروع به فعالیت نمودند. رفته‌رفته مدیران این كارگاه‌ها تصمیم گرفتند، به كار خود وسعت ببخشند. تا جایی كه با توانایی‌های شخصی خود قادر به اداره آن نبودند. به عبارتی دچار بحران سازمان یا بحران سیستم شدند. در چنین وضعیتی مدیر سازمان تصمیم می‌گیرد به كمك ERP  مشكل سازمان را برطرف كند. چنین فردی در ابتدای امر ERP  را در حد چند خط برنامه‌نویسی می‌بیند و رفته‌رفته پی می‌برد كه ERP گامی فراتر از برنامه‌نویسی صرف است.  ما در عمل با سازمان‌هایی مواجه  می‌شویم كه زیرساخت لازم برای تهیه و استقرار ERP را ندارند. ممكن است مدیری كاری را در سطح بسیار عالی انجام دهد اما در سطوح بالاتر برای انجام همان كار با مشكل مواجه شود.

این مشكل به دلیل آن است كه آن مدیر كارهایش را تنها بر اساس هوشمندی انجام می‌داده است اما حالا كه وسعت سیستم زیاد شده، باید زیرساخت‌های لازم برای سازمان فراهم باشد تا سازمان به حیات خود ادامه دهد.  در مجموع، من معتقدم با یك صورت مسئله ناشناخته مواجه هستیم و با خواسته‌های بسیار جاه‌طلبانه‌ای كه انطباق آن با ERP مورد انتظار بسیار مشكل خواهد بود. شاید خواسته‌های یك سازمان، دست نیافتنی باشد، این امر شاید به دلیل اطلاعات ناكافی یا مشاوران كم اطلاع باشد.  جایگزینی سیستم به جای انسان كار دشواری است. ما در برخورد با یك پروژه، با عدم شناخته بودن نیازها مواجه هستیم. در مرحله بعدی، نتایج مورد انتظار برای برآورده شدن آن نیازها هم مشخص نیست. معلوم نیست تعهدات یك پیمانكار چه وقت به اتمام می‌رسد و چه كارهایی جزء تعهدات پیمانكار محسوب  می‌شود.

علیرضا علاوش: شركت سبزداده‌افزار با 11 سال سابقه كار در زمینه ارائه راه‌حل‌های برنامه‌ریزی منابع سازمانی دارای دو خط تولید اصلی است. یك خط شامل تولید بسته‌های نرم‌افزاری (greensigma)  و دیگری شامل ارایه راه‌حل‌های برنامه‌ریزی منابع سازمانی (Greenerp) می‌باشد. بنابراین عدم شناخت سازمان از خود باعث  می‌شود در بسیاری از موارد سازمان از شركت تولیدكننده ERP انتظارات نامعقولی داشته باشد. در خصوص شناخت نیاز مشتری، مشكلی كه شركت‌های تولیدكننده ERP  در بدو ورود به سازمان یا حتی قبل از آن با آن مواجه هستند، نبود RFP است كه به این سئوال پاسخ می‌دهد كه آیا شركت تولیدكننده ERP توان تأمین خواسته‌های سازمان كارفرما را دارا خواهد بود یا خیر؟ در این صنعت به شدت با این مشكل مواجه هستیم كه حتی در صورت وجود، به دست شركت می‌رسد، یك كپی‌برداری بدون توجه به نیاز سازمان سرویس‌گیرنده است.

شركت تولیدكننده ERP بعد از ورود به سازمان سرویس‌گیرنده متوجه این موضوع  می‌شود كه RFP ارایه شده با نیازهای سازمان تناقض دارد. مشكل بعدی این است كه اگر حتی از درون سازمان، اطلاعات برای تهیه RFP استخراج شود، از همان ابتدای امر، با مقاومت مواجه  می‌شود و جمع‌آوری اطلاعات با انواع محدودیت‌ها دچار اشكال است. هر بخش سازمان نیازهای خود را به صورت جزیره‌ای مطرح می‌كند. درحالی كهERP یك نرم‌افزار یكپارچه است. در بعضی مواقع شاید نیاز سازمان در حد MIS یا جمع‌آوری اطلاعات باشد. این مشكل در ابتدای امر بسیار دردسرساز خواهد بود. عموماًRFP ها یك سری عواقب در هنگام اجرا دارند.  وقتی وارد حوزه پیاده‌سازی ERPمی‌شویم همینRFP ناقص و نامنطبق با نیازهای سازمان، به عنوان یكی از مستندات اصلی در اجرای قرارداد در نظر گرفته می‌شود و بندهای قراردادی مستقیماً با بندهای RFP مرتبط می‌شود. در بعضی از قراردادها 50 درصد ازRFP ، براساس نیاز سازمان قابل تغییر است و این یك چالش دیگر است. در اجرای یك پروژه ERP هر دو طرف كارفرما و پیمانكار مسئول هستند.  پس این كه تمام مسئولیت یك پروژه ERP بر دوش تولیدكننده آن قرار می‌گیرد نگرش اشتباهی است. در این بین نباید از كارفرما سلب مسئولیت شود.

ما به عنوان یك پیمانكار یا یك پزشك وارد سازمان می‌شویم، قرار است مشكلات سازمان را برطرف كنیم و آن سازمان هم دچار معلولیت‌هایی است كه تا وقتی ERP استقرار پیدا نكرده این معلولیت‌ها هم ناشناخته باقی خواهند ماند.  قطعاً به این دلیل كه ما به راه‌حل‌های مشابه شناخت داریم، می‌توانیم به عنوان یك پزشك راه درمان را ارایه كنیم و اگر این حس اعتماد بین كارفرما و پیمانكار ایجاد شود، كارفرما می‌تواند روش‌های سنتی خود را اصلاح كند. این مشكلات بین شركت‌های نرم‌افزاری مشترك است. چه در ارائه راه‌حل و چه در مسایل فرهنگی و قوانین، مشكلات شناخته شده است. به جای بیان جداگانه آنها می‌خواهیم این مشكلات را از یك تریبون بیان كنیم تا بتوانیم برای مشكل مشترك راه‌حل مشترك پیدا كنیم.

بهرنگ عاصمی: فقدان rfp و rfpهای ناقص یا غیر قابل پیاده‌سازی مشكل بزرگی است. طبیعی است كه طی سیر تهیه یك RFP و ارایه آن به شركت‌های تولیدكننده راه‌حل، و همچنین در كلیه مراحل انتخاب راه‌حل مناسب برای سازمان، وجود مشاور و یا ناظر در استقرار موفق پروژه، بسیار مؤثر است. در كشور ما متأسفانه تعریف دقیقی از مشاور یا ناظر ارائه نشده و این مسئله به مشكل تهیه RFP دامن می‌زند. حتی در بسیاری از پروژه‌ها، هیچ ناظر یا مشاوری وجود ندارد. شما به عنوان شركت ارایه‌دهنده راه‌حل‌های ERP در این خصوص با چه مشكلاتی مواجه هستید؟ آیا این مشكلات راه‌حلی هم دارد و شركت شما برای حل این مشكل چه راهكاری دارد؟

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

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

درواقع اعتماد یك كاخ شیشه‌ای غیرقابل اتكا است. پس پیمانكار مجبور است مراقب حفظ اعتماد مدیران سازمان كارفرما باشد. حال فرض كنید در این بین یك مشاور هم وجود دارد كه بدون داشتن شناخت كافی از مشكلات سازمان، مرتباً با به حاشیه كشاندن كار مشكلاتی در روند آن ایجاد می‌كند. پس در مدلی كه كار ما حول محور اعتماد شكل می‌گیرد و ابزار ما برای سرویس دادن به سازمان و حتی گرفتن پروژه همین اعتماد است، و پشتوانه فنی و سیستماتیك حداقل است؛ حفظ و به نتیجه رساندن چنین پروژه‌ای با ریسك بسیاری مواجه است. چون ممكن است هر مسئله كوچكی باعث خدشه‌ این اعتماد شود و پروژه ناتمام بماند. پس مجری طرح همواره نگران است كه این اعتماد از بین برود و پروژه به نتیجه نرسد.

باید از هر چیزی كه این اعتماد را خدشه‌دار می‌كند، پرهیز شود.  در این شرایط مشاوران بیشتر باعث ایجاد تنش خواهند شد و پیمانكاران را متهم به عمل نكردن به تعهداتشان و پروژه با انتظارات كارفرما می‌كنند. ما باید به دنبال شناخت نیازها و اولویت‌ها در پروژه‌ها باشیم كه متاسفانه زیاد مورد توجه قرار نمی‌گیرد. نقش مشاوران در تعیین اولویت‌ها بسیار پررنگ است. بی‌توجی به این نكته تبعات زیادی در پی دارد. از تهیه RFP گرفته تا انتخاب پیمانكار و چه در طول كار، مشاوری كه از اولویت‌ها و مشكلات سازمان مطلع است و بر امر تدریج اشراف دارد، می‌تواند نقش بسیار مؤثری ایفا نماید.

علیرضا علاوش: شركت سبزداده‌افزار هم با چنین مشكلاتی این چنینی مواجه بوده است. سازمان‌هایی كه RFP ارائه نمی‌كنند، و عدم حضور مشاور هنگام اجرا چالش‌های زیادی ایجاد كرده است. مشكل اصلی كه در ایران وجود دارد این است كه master plan در سازمان‌ها وجود ندارد تا از آن action plan و پس از آن RFP استخراج شود.  این موضوع به دلیل نبود این مستندات و برنامه‌ریزی بلندمدت چه در سازمان‌های دولتی و چه سازمان‌های خصوصی است كه باعث می‌شود RFP‌هایی تولید شوند كه بعضاً با RFP‌های بعدی تداخل دارند. ما پروژه‌هایی را می‌شناسیم كه به اسم ERP شروع  می‌شوند و بعد از اجرا مشخص  می‌شود كه بخش‌هایی از فرآیندهای سازمان به هیچ وجه درنظر گرفته نشده است، و چون تأمین اعتبار نشده، مجبور به استفاده از نرم‌افزار دیگری در سازمان شده‌اند. در حقیقت مسیر راه از اول مشخص نبوده و مراحل تهیه RFP به درستی طی نشده است. اگر به این مشكل درست رسیدگی شود نقش مشاور و ناظر و تعهدات پیمانكار هم كاملاً مشخص خواهد شد. بسیاری از شركت‌ها فعالیت در این راه را آغاز كردند. همانطور كه می‌دانیم یك پروژه، گاه چند سال نیاز به كار دارد.  این امر هدف‌گذاری را نیازی مهم نشان می‌دهد: ابتدا اهداف اصلی و بعد اهداف فرعی از قبل پیش‌بینی‌شده. اگر روند تهیه RFP به درستی طی شود وظایف ناظر و مشاور و پیمانكار به وضوح مشخص خواهد شد. به هر حال یكی از مشكلات بزرگ صنعت نرم‌افزار نبود همین مشاور است.  در كار ما با بدنه سازمان مواجه هستیم و power user ها در این بین بسیار مهم هستند. تحویل گیرنده كار هم بسیار مهم است. امروزه تعطیلی پروژه‌های ERP به یك معضل تبدیل شده است. چون در RFP، مرزی برای خواسته‌های كارفرما مشخص نشده است. در حالی كه اگر از اول power user ها مشخص می‌شدند و اینكه چه كسی قرار است كار را از پیمانكار تحویل بگیرد و مرز پروژه كجاست، قطعاً درگیری‌ها بین پیمانكار و كارفرما به وجود نمی‌آمد و اعتماد بین آنها از بین نمی‌رفت. دلیل این امر آن است كه ما باید خودمان راه‌حل ارایه دهیم، ناظر پروژه باشیم، به دنبال تحویل‌گیرنده باشیم تا بتوانیم قرارداد را به سرانجام برسانیم. اما در مورد بسته‌های نرم‌افزاری این مشكل به صورتی كه گفته شد، وجود ندارد.

پیروز سلطانی: مهمترین مشكل در ERP نبود تعریف درستی از كار از طرف كارفرما و حتی بعضاً از جانب خود پیمانكار است. چون گاهی خود پیمانكار هم تعریف درستی از نرم‌افزاری كه قرار است به مشتری ارایه شود، ندارد. مرز آن را نمی‌دانند و حتی ما معتقدیم برای ERP نمی‌توان پایانی تصور كرد. چون باید كم كم در آن پیش رفت و رشد داد تا در نهایت تمام فرآیندها در یك نظام اطلاعاتی یكپارچه برنامه‌ریزی شوند.  مشكل دیگر، این تصور ناصحیح است كه ERP مخصوص سازمان‌های بالغ و بدون مشكل است. در صورتی كه ما معتقدیم ERP بیشتر به درد سازمان‌هایی می‌خورد كه مشكل دارند تا در برنامه‌ریزی به آنها كمك كند. در بحث هزینه‌ها وقتی سازمان دچار مشكل است، برای او مشكل خواهد بود كه هزینه كند. چنین راه‌حل‌هایی برای این سازمان‌ها كم‌هزینه نیست، زیرا راه‌حلی نیست كه با یك كپی‌برداری قابل استفاده باشد. بلكه برعكس باید آرام وارد سازمان شود، افراد قوی و با حوصله روی آن كار كنند. رفتن به سمت ERP باید با دید سرمایه‌گذاری توأم باشد. سازمانی كه مشكل دارد،  باید بپذیرد همان قدر كه كنترل انبار برایش حیاتی است، به همان میزان ERP هم برای او مهم است. در نهایت ERP باید سازمان را به رشد مورد نظر برساند.

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

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

بهرنگ عاصمی: یكی از مشكلاتی كه در صحبت‌ها مشهود بود، نگرش سنتی مدیران به ERP است. یكی از آثار منفی این نگرش سنتی، تكنولوژی‌زدگی و انتخاب جدیدترین تكنولوژی روز است و امیدواری به این كه آخرین تكنولوژی می‌تواند نیازهای سازمان را برآورده نماید.  این در حالی است كه در بسیاری از سازمان‌ها این نتیجه به وضوح قابل برداشت است كه تنها استفاده از تكنولوژی، نه تنها مشكل سازمان را برطرف نمی‌كند، بلكه بدون توجه به بحث دانش و اصلاح فرآیندهای سازمانی و ساختار آن، هزینه‌های سازمان را نیز چندین برابر می‌كند. در حقیقت، بسیاری سازمان‌ها با یك نگرش مبتنی بر ابزار به حل مسئله پرداخته‌اند كه رویكردی ناموفق بوده است.

محمد ظاهری: در اینجا من سه ویژگی مهم مدیران سنتی ایران را بیان می‌كنم: 1 - كسب‌وكار را حول اعتماد شكل می‌دهند. مثلاً از نظر مدیران ایرانی، مدیر مالی خوب، یك حسابدار خوب نیست، بلكه یك فرد رازدار و ریزبین را یك مدیر مالی خوب محسوب  می‌شود. 2 - بسیار نتیجه‌گرا هستند و صرفاً می‌خواهند، كاری انجام شود. شاید این خصیصه در بعضی جاها قابل تحسین باشد. اما توجه آن برای پیمانكار مهم است، زیرا در صورت شكست پروژه، پیمانكار نمی‌تواند برای چنین مدیری دلیل ارایه دهد تا توجیه كننده  شكست كار باشد. نمی‌تواند چنین مدیری را قانع كرد می‌شود كار بی‌نتیجه بماند كه در بعضی موارد كوتاهی از جانب همان مدیر بوده كه باعث بی‌نتیجه ماندن كار شده است. به عبارتی پیمانكار مجبور است همیشه موضوع را فراتر از آن چیزی ببیند كه مطرح  می‌شود. واقعاً مسایل سازمان جزیی از مسایل پیمانكار خواهد شد چون مدیر توقع دارد كه پروژه حاضر به نتیجه برسد. 3 - بی‌حوصله و عجول هستند و می‌خواهند با تصمیم‌گیری‌های فردی و فوری در زمان خود صرفه‌جویی كنند. در چنین ساختار سنتی، اگر بخواهیم مفید واقع شویم و مشكلی را حل كنیم نیاز به كار بیشتر داریم. صرفاً استفاده از تكنولوژی خوب، باعث حل تعارضات سازمانی و ضعف دانش سازمان نمی‌شود. باز هم به همان نقطه شروع، یعنی نیاز می‌رسیم. ما باید نیاز سازمان را بشناسیم. استفاده از تكنولوژی بالا، تضمین‌كننده برطرف شدن مسایل مشتری نیست. در شهری كه مسیری برای تردد ماشین وجود ندارد، خرید ماشینی با قیمت و تكنولوژی بالا كاملاً بی‌معنی است. در چنین موقعیتی یك دوچرخه با وجود تكنولوژی پایین‌تر از ماشین كارآمدتر و كم‌هزینه‌تر، مشكل فرد را برطرف می‌كند. تكنولوژی در جامعه ما تبدیل به نقابی برای سازمان‌ها شده است. نقابی برای پنهان كردن ضعف در سرویس، دانش، و در توانایی‌ها. اینكه گاه گفته می‌شود ایران گورستان تكنولوژی‌هاست، مطلب قابل تاملی است. هنگامی كه تكنولوژی به ایران می‌آید نه تنها منفعتی برای بسیاری سازمان‌ها ندارد، بلكه هزینه‌های اضافی هم به سازمان تحمیل می‌كند. نگاه نادرست به تكنولوژی، آن را به دامی تبدیل می‌كند كه سازمان را به بیراهه می‌كشاند. من معتقدم سطح تكنولوژی مورد انتظار، باید كاملاً مشخص شود.

من بارها گفته‌ام كه تكنولوژی ERP، یك تكنولوژی وارداتی نیست، بلكه مولود نیازهای سازمان است و همین نیازها باعث شده تا مدیران سازمان به فكر استقرار ERP بیفتند. این نگرش كه هر سازمان نیازهای خاص خود را داراست و اینها باید به صورت فرآیندی و یكپارچه پیاده‌سازی شوند در ایران به وجود آمده است. من هم روی این موضوع تاكید می‌كنم كه ما در كشوری هستیم كه با همه دنیا متفاوت است.  به همین دلیل است كه ERP وارداتی در سازمان ایرانی كاربردی ندارد. مشكلی كه در بنیان یك سازمان است باید به صورت بنیادین هم حل شود. در مورد پرسش آقای عاصمی مبنی بر نسبت تكنولوژی با ERP معتقدم مهم حل مسئله است، نه صرفاً استفاده از یك تكنولوژی یا ابزار خاص. پس نباید موضوع را در حد یك تكنولوژی یا ابزار تنزل داد. ERP فقط یك نرم‌افزار نیست. مباحث علوم انسانی و مدیریتی و مقوله تغییر، هسته اصلی كسب و كار ماست. قرار است به واسطه اصلاح فرآیندها ارزشی در سازمان ایجاد شود. پس این كار نباید در حد تولید یك نرم‌افزار تنزل یابد. بنابراین خصلت نتیجه‌گرایی مدیران ما در اینجا مفید خواهد بود.

علیرضا علاوش: این كه در ایران سازمان‌ها با مشكلات خاص خود مواجه هستند، كاملاً درست است. حتی اگر مدیران از نظر مالی مشكلی برای ورود یك تكنولوژی به سازمان نداشته باشند، باز هم ورود تكنولوژی جدید، نیاز به مدیریت و برنامه‌ریزی دارد. 8 سال پیش پروژه‌ای با بودجه میلیاردی در ایران مطرح شد كه برای اجرای آن 60 نفر نیروی متخصص آموزش دیدند.  بعد ها به دلیل تغییر مدیریت این پروژه به دست فراموشی سپرده شد و 58 نفر از افرادی كه به خاطر همین پروژه در ایران آموزش دیده بودند به تیم پروژه مشابهی در خارج از كشور ملحق شدند و در عمل تمام بودجه مصرف شده در امر آموزش افراد به هدر رفت.  در حالی كه شاید این پروژه می‌توانست با امكانات و تكنولوژی موجود، بدون نیاز به آموزش افراد هم اجرا شود.

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