استقرار ارزان اودو؛ چرا انتخاب تیم بی‌تجربه می‌تواند گران تمام شود؟

قیمت پایین از کجا آمده است؟

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

تحلیل فرایندها، بررسی کیفیت داده‌ها، تنظیم دسترسی‌ها، آموزش کاربران و آزمایش ارتباط واحدها، همگی به زمان و تخصص نیاز دارند. اگر این فعالیت‌ها در پیشنهاد اولیه دیده نشده باشند، نیاز سازمان به آن‌ها از بین نمی‌رود؛ فقط هزینه‌شان به مراحل بعد منتقل می‌شود.

برای مثال، عبارت «راه‌اندازی انبار» می‌تواند دو معنای کاملاً متفاوت داشته باشد:

نصب ماژول انبار و تعریف چند کالا؛

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

مقایسه قیمت این دو خدمت، بدون مقایسه خروجی آن‌ها، تصمیم‌گیرنده را به نتیجه اشتباه می‌رساند. در پروژه ERP باید روشن باشد هر مبلغ دقیقاً در برابر چه تعهدی پرداخت می‌شود.

اولین خطر: تحویل نسخه کرک‌شده با عنوان اودوی کامل

یکی از مواردی که باید پیش از قرارداد روشن شود، نسخه نرم‌افزار و وضعیت مجوز استفاده از آن است.

نرم افزار Odoo دو  ویرایش Community و Enterprise دارد. نسخه Community متن‌باز است و استفاده از آن مطابق مجوز مربوط، به‌خودی‌خود به معنای استفاده از نرم‌افزار کرک‌شده نیست. در مقابل، استفاده از Enterprise تابع مجوز و اشتراک معتبر مربوط به آن است. بنابراین «Community رایگان» و «Enterprise کرک‌شده» دو موضوع متفاوت‌اند.

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

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

پیش از انتخاب تیم استقرار، پاسخ این پرسش‌ها باید مشخص باشد:

• کدام ویرایش و نسخه اودو تحویل داده می‌شود؟

• مجوز استفاده از نرم‌افزار و افزونه‌ها چگونه تأمین می‌شود؟

• چه تغییراتی روی کد اصلی اعمال شده است؟

• مسئول نگهداری و سازگاری این تغییرات با نسخه‌های بعدی چه کسی است؟

وعده «همه امکانات با کمترین هزینه» به خودی خود بدون این پرسش‌ها عجیب هست چه برسد به اینکه   صرفا با این ادعا  اطلاعات و عملیات سازمان را در اختیارشان قرار دهید.

دومین خطر: برای هر درخواست، یک ماژول جدید می‌نویسند

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

تیم بی‌تجربه ممکن است برنامه‌نویسان توانمندی داشته باشد، اما چون امکانات اودو را کامل نمی‌شناسد، بسیاری از درخواست‌ها را مستقیماً به کدنویسی تبدیل کند. مشتری هم تعداد زیاد توسعه‌ها را نشانه توجه مجری به نیازهای خود بداند.

نتیجه می‌تواند سیستمی باشد که برای انجام کارهای معمول، به مجموعه‌ای از افزونه‌های اختصاصی وابسته شده است؛ افزونه‌هایی که هرکدام به نگهداری، رفع خطا و بررسی سازگاری نیاز دارند.

مثال فنی: تأمین کالا پس از کاهش موجودی

مدیر انبار می‌گوید: «وقتی موجودی یک کالا کم شد، می‌خواهم فرایند خرید آن آغاز شود.»

تیمی که قابلیت‌های استاندارد را نمی‌شناسد، ممکن است یک برنامه زمان‌بندی‌شده اختصاصی بنویسد که موجودی را بررسی و سند خرید ایجاد کند.

درحالی‌که اودو برای این نیاز، قواعد سفارش مجدد دارد. با تنظیم حداقل و حداکثر موجودی و مسیر تأمین، می‌توان فرایند تأمین کالا را بر اساس موجودی پیش‌بینی‌شده سامان داد. انتخاب تنظیم مناسب نیز به زمان تأمین، سفارش‌های باز و شرایط عملیاتی سازمان بستگی دارد.

اگر راهکار اختصاصی بدون توجه به همین منطق نوشته شود، ممکن است سفارش‌های در راه را نادیده بگیرد و خرید تکراری ایجاد کند. در چنین شرایطی، سازمان برای بازنویسی قابلیتی هزینه داده که از ابتدا در نرم‌افزار وجود داشته است.

مثال فنی: ثبت صورتحساب بر اساس کالای دریافت‌شده

واحد مالی می‌خواهد صورتحساب تأمین‌کننده با کالای دریافت‌شده تطبیق داشته باشد. تیم کم‌تجربه ممکن است پیشنهاد ساخت فرم کنترل جداگانه بدهد.

اما Odoo  سیاست کنترل صورتحساب بر مبنای مقدار دریافت‌شده و قابلیت تطبیق سه‌طرفه سفارش خرید، رسید کالا و صورتحساب را در اختیار می‌گذارد. ابتدا باید بررسی شود این امکانات تا چه اندازه نیاز سازمان را پوشش می‌دهند؛ سپس درباره کنترل‌های تکمیلی تصمیم گرفت.

تخصص در استقرار اودو یعنی تشخیص اینکه کدام نیاز با تنظیمات حل می‌شود و کدام نیاز واقعاً به توسعه احتیاج دارد.

البته همه نیازها در امکانات پیش‌فرض پوشش داده نمی‌شوند. اتصال به سامانه‌های داخلی، الزامات بومی ایران یا بعضی فرایندهای تخصصی ممکن است به توسعه نیاز داشته باشند. مسئله، ضرورت و کیفیت این توسعه است: باید دلیل مشخص، طراحی سازگار با معماری اودو و برنامه نگهداری داشته باشد.

سومین خطر: اودو را درست انتخاب می‌کنید، اما مجری را اشتباه

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

اما یک نرم‌افزار واحد می‌تواند در دو سازمان، با دو تیم اجرایی، نتایج بسیار متفاوتی ایجاد کند.

یک تیم، ارتباط فروش، انبار و مالی را بر اساس منطق استاندارد تنظیم می‌کند. تیم دیگر ممکن است برای هر واحد، فرم‌ها و گردش‌های جداگانه بسازد؛ تا جایی که اطلاعات ظاهراً در یک نرم‌افزار قرار دارند، اما فرایندها همچنان جزیره‌ای کار می‌کنند.

در نگاه اودو ایران، می‌توان اهمیت این انتخاب را با نسبت ۷۰ درصد تیم استقرار و ۳۰ درصد قابلیت‌های نرم‌افزار توضیح داد. این نسبت، بیان دیدگاه ما درباره وزن تصمیم اجرایی است: امکانات اودو زمانی به نتیجه تبدیل می‌شوند که تیم مجری بتواند آن‌ها را متناسب با سازمان به کار بگیرد.

وقتی تغییر مستقیم هسته، ارتقا را پرهزینه می‌کند

فرض کنید برای تغییر رفتار تأیید سفارش فروش، فایل اصلی ماژول فروش مستقیماً ویرایش شده باشد. در کوتاه‌مدت، درخواست مشتری انجام شده و همه‌چیز درست به نظر می‌رسد.

اما هنگام به‌روزرسانی، فایل تغییرکرده ممکن است جایگزین شود یا با کد جدید تعارض پیدا کند. اگر تغییرات مستند و نسخه‌بندی نشده باشند، تیم نگهداری باید ابتدا کشف کند چه چیزی تغییر کرده و چرا.

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

مستندات رسمی اودو نیز برای ارتقای پایگاه داده دارای ماژول‌های اختصاصی، سازگار کردن کد و انجام آزمون را بخشی از مسیر ارتقا می‌داند. بنابراین وجود توسعه اختصاصی الزاماً مانع ارتقا نیست؛ توسعه بی‌ضابطه می‌تواند این مسیر را دشوار و پرهزینه کند.

باز شدن نرم‌افزار، نشانه موفقیت ارتقا نیست

پس از ارتقا، ممکن است کاربران وارد سیستم شوند و فرم‌ها نیز نمایش داده شوند؛ اما فرایند کامل درست کار نکند.

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

برای مدیرعامل، این مشکل به معنای اختلال در عملیات است؛ برای مدیر مالی، احتمال مغایرت؛ و برای مدیر فناوری اطلاعات، وابستگی به کدی که نگهداری آن دشوار شده است.

چهارمین خطر: قیمت اولیه پایین است، اما هزینه نهایی مشخص نیست

بعضی پیشنهادها فقط هزینه ورود به پروژه را نشان می‌دهند. پس از شروع، سازمان متوجه می‌شود فعالیت‌هایی که ضروری می‌دانسته، خارج از قرارداد بوده‌اند:

• انتقال و پاک‌سازی اطلاعات؛

• تنظیم فرایندهای بین واحدها؛

• تعریف دسترسی‌های متناسب با مسئولیت افراد؛

• آموزش کاربران و مدیران؛

• اصلاح خطاهای دوره آغاز بهره‌برداری؛

• نگهداری توسعه‌ها و سازگار کردن آن‌ها با نسخه‌های بعدی.

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

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

هزینه واقعی استقرار اودو، مجموع هزینه راه‌اندازی، بهره‌برداری، نگهداری، ارتقا و دوباره‌کاری‌های احتمالی است.

رویکرد اودو ایران؛ شناخت نرم‌افزار پیش از توسعه آن

در اودو ایران، مبنای استقرار، شناخت فرایند سازمان و استفاده حداکثری از ظرفیت‌های خود اودو است.

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

برای مثال، وقتی یک مدیر درخواست «ساخت یک فرم جدید» دارد، ابتدا باید مشخص شود قرار است چه مسئله‌ای حل شود. ممکن است همان نیاز با تنظیم یک گردش موجود، استفاده از اطلاعات ثبت‌شده یا اصلاح سطح دسترسی پاسخ بگیرد. ساخت فرم تازه، پیش از این بررسی، می‌تواند فقط پیچیدگی بیشتری ایجاد کند.

اولویت ما: پاسخ‌گویی به ۹۵ درصد نیازها با امکانات پیش‌فرض

رویکرد اودو ایران، پاسخ‌گویی به حدود ۹۵ درصد نیازهای کسب‌وکار از طریق امکانات پیش‌فرض و پیکربندی نرم‌افزار است. میزان تحقق این هدف در هر سازمان، پس از تحلیل نیازها و با توجه به نسخه، ماژول‌ها و الزامات آن مشخص می‌شود.

این رویکرد بر تسلط به قابلیت‌های اودو تکیه دارد. برای هر درخواست، ابتدا امکانات موجود بررسی می‌شوند و تنها زمانی به توسعه اختصاصی می‌رسیم که شکاف واقعی و مشخصی باقی مانده باشد.

برای مثال، در بررسی درخواست یک گزارش مدیریتی، ابتدا باید دید اطلاعات موردنیاز در سیستم ثبت می‌شوند یا نه، ساختار ثبت آن‌ها درست است یا نه و گزارش‌های موجود چه بخشی از نیاز را پاسخ می‌دهند. گاهی مسئله با اصلاح تنظیمات و شیوه ثبت اطلاعات حل می‌شود؛ گاهی نیز ساخت گزارش اختصاصی توجیه دارد.

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

استقرار، توسعه و آموزش، اختصاصی برای هر سازمان

در اودو ایران، خدمات استقرار، توسعه و آموزش به‌صورت اختصاصی برای همان سازمان انجام می‌شود. جلسات آموزشی بر پایه ویدئوهای از پیش ضبط‌شده نیستند؛ آموزش با فرایندها، نقش‌ها و سناریوهای کاری واقعی مشتری پیش می‌رود.

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

از نگاه ما، شخصی‌سازی اودو از شناخت کسب‌وکار آغاز می‌شود و می‌تواند در تنظیمات، گردش کار، دسترسی‌ها، گزارش‌ها و آموزش اختصاصی نمود پیدا کند. کدنویسی، یکی از ابزارهای این مسیر است و زمانی استفاده می‌شود که ضرورت آن روشن باشد.