سیستم‌سازی سازمان پیش از ERP: چهار لایه‌ای که هیچ نرم‌افزاری به‌تنهایی نمی‌سازد

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

این تجربه استثنا نیست. پژوهشی دانشگاهی دربارهٔ پروژه‌های ERP در شرکت‌های ایرانی، ۵۸ عامل شکست را شناسایی و در هفت دسته گروه‌بندی کرده است. فقط یکی از این هفت دسته فنی است. بقیه سازمانی، مدیریتی، انسانی و فرایندی‌اند. یعنی بیشتر چیزهایی که پروژهٔ ERP را زمین می‌زنند، در خود نرم‌افزار نیستند.

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

نشانه‌ها: سازمان شما سیستم دارد یا فقط ابزار سیستم؟

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

سه عدد برای یک «فروش»

مدیر فروش می‌گوید فروش ماه گذشته پنجاه‌ودو میلیارد تومان بود، مدیر مالی چهل‌وهفت و مدیر انبار چهل‌ونه. هر سه از همان نرم‌افزار گزارش گرفته‌اند. هیچ‌کدام اشتباه نکرده‌اند؛ یکی سفارش تأییدشده را شمرده، یکی فاکتور صادرشده و یکی کالای تحویل‌شده را. این نشانهٔ نبود حکمرانی داده است.

شاخص سبز، مشتری ناراضی

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

فرایند روی کاغذ، تلفن در عمل

فرایند خرید سه امضا دارد. در عمل، سفارش‌های فوری با یک تماس تلفنی تأیید می‌شوند و امضاها بعداً گرفته می‌شوند. این شکاف در فرایند و کنترل است؛ گلوگاه فرایندی پنهانی که در هیچ نقشه‌ای دیده نمی‌شود.

کسی که اگر برود، همه‌چیز می‌ایستد

سرپرست تولیدی که همهٔ راه‌های میانبُر را بلد بود، استعفا داده است. با او دانشی رفته که هیچ‌جا ثبت نشده بود. این نشانهٔ سازمان وابسته به افراد است؛ سیستم روی کاغذ وجود دارد، اما در عمل در ذهن چند نفر زندگی می‌کند.

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

سیستم‌سازی سازمان چیست؟

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

سه مفهوم معمولاً با هم اشتباه گرفته می‌شوند:

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

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

چرا پروژه‌های ERP شکست می‌خورند؟

شکست پروژهٔ ERP معمولاً ناگهانی نیست. از همان اول در انتخاب‌هایی کاشته می‌شود که هیچ ربطی به نرم‌افزار ندارند.

هفت دسته عامل شکست در شرکت‌های ایرانی

پژوهشگران دانشگاه سمنان عوامل شکست ERP را از پژوهش‌های پیشین گرد آوردند، با کمک خبرگان موارد تکراری را ادغام کردند و به ۵۸ عامل رسیدند. این عوامل در هفت دسته جا گرفتند:

1. سازمانی

2. مدیریت پروژه

3. منابع انسانی

4. مدیریتی

5. فروشندگان و مشاوران

6. فرایندی

7. فنی

برداشت ما از این فهرست ساده است: شش دسته از هفت دسته، پیش از نصب نرم‌افزار تعیین می‌شوند. دستهٔ پنجم هم مستقیم به انتخاب شریک استقرار برمی‌گردد.

الگوی مشترک: خودکارکردن بی‌نظمی

وقتی تعریف داده روشن نیست، حق تصمیم مشخص نیست و فرایند واقعی با فرایند روی کاغذ فرق دارد، یکی از دو اتفاق می‌افتد:

• نرم‌افزار خودش تصمیم می‌گیرد. تنظیمات پیش‌فرض به جای سیاست سازمان می‌نشیند و کسی نمی‌داند چرا.

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

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

چهار لایهٔ سیستم‌سازی در نگاه دیباگ

ما در دیباگ سازمان را از پایین به بالا می‌سازیم: داده، سیستم، فرایند و انسان. هر لایه به لایهٔ پایین‌تر تکیه می‌کند؛ و اودو زیرساختی است که هر چهار لایه را اجرا می‌کند. 

معماری چهارلایهٔ سیستم‌سازی دیباگ و جایگاه اودو

لایهٔ ۱: حکمرانی داده

حکمرانی داده (یا حاکمیت داده) یعنی تعیین اینکه چه کسی دربارهٔ داده تصمیم می‌گیرد و چه کسی پاسخگوست. DAMA International، مرجع بین‌المللی مدیریت داده، آن را اعمال اختیار، کنترل و تصمیم‌گیری مشترک بر دارایی‌های داده تعریف می‌کند.

پنج حوزهٔ تصمیم داده

خاتری و براون این تصمیم‌ها را در پنج حوزه دسته‌بندی کردند: اصول داده، کیفیت داده، فراداده، دسترسی و چرخهٔ عمر داده. مشکل «سه عدد برای یک فروش» در سه حوزهٔ اول ریشه دارد: کسی تصمیم نگرفته که «فروش» برای هیئت‌مدیره کدام است، و هیچ تعریفی در فرهنگ دادهٔ سازمان (data dictionary) ثبت نشده.

لایهٔ ۲: سیستم

دانلا مدوز نشان داده رفتار هر سیستم تا حد زیادی از ساختار خودش می‌آید.

انباشت، بازخورد و تأخیر

نقدینگی، موجودی و تجربهٔ کارکنان انباشت‌اند؛ گزارش ماهانه معمولاً فقط جریان‌ها را نشان می‌دهد. هر تصمیم ورودی تصمیم بعدی است و نتیجه‌اش با تأخیر می‌رسد. ماجرای «شاخص سبز، مشتری ناراضی» همان الگویی است که دانلد کمپبل توصیف کرد: هرچه شاخصی بیشتر مبنای تصمیم شود، بیشتر فاسد می‌شود.

لایهٔ ۳: فرایند و کنترل

پنج چرخهٔ عملیات و مدل REA

رامنی و همکاران، در کتاب مرجع سیستم‌های اطلاعاتی حسابداری، سازمان را در چرخه‌های عملیات می‌بینند: فروش تا وصول، خرید تا پرداخت، تولید، منابع انسانی و حقوق، و دفتر کل. مدل دادهٔ REA هر رویداد را با منبعی که جابه‌جا می‌شود و عاملی که در آن نقش دارد، ثبت می‌کند. کنترل هم از «محیط کنترلی» شروع می‌شود؛ یعنی از رفتار مدیران، نه از تعداد امضاها.

لایهٔ ۴: انسان

چرا کنترل بیشتر همیشه بهتر نیست

انسان هم داده را می‌سازد، هم تصمیم می‌گیرد و هم فرایند را اجرا می‌کند یا دور می‌زند. در یک آزمایش میدانی، افزودن کنترل عملکرد کارهای دشوار را پایین آورد؛ این اثر از کارکنانی بود که انگیزهٔ غیرمالی داشتند (Herz & Zihlmann, 2024). به همین دلیل ما کنترل‌ها را برای موارد پرخطر طراحی می‌کنیم، نه برای بی‌اعتمادی به همه. پذیرش یک سیستم تازه هم بیش از هر چیز به همین لایه بستگی دارد.

حسابداری مدیریت: زبان تصمیم

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

سازمان شما در کدام لایه گیر کرده است؟ در یک جلسهٔ کوتاه، چهار لایهٔ سازمانتان را با مشاوران دیباگ مرور کنید و ببینید از کجا باید شروع کرد. درخواست ارزیابی چهارلایه

اودو کجای این نقشه است؟

اودو (Odoo) یک ERP ماژولار است و تقریباً همهٔ چرخه‌های لایهٔ سوم را پوشش می‌دهد. اما همین انعطاف است که آن را در دست سازمانی که هنوز نمی‌داند چه می‌خواهد، خطرناک می‌کند: اودو هر شکلی را می‌پذیرد، حتی شکل بی‌نظمی را.

آنچه اودو به‌صورت استاندارد پوشش می‌دهد

• فروش، CRM و صدور فاکتور

• خرید و انبار

• تولید (MRP)

• حسابداری و حسابداری تحلیلی

• کارکنان، پروژه و ثبت زمان

یعنی زیرساخت فنی برای هر چهار لایه آماده است. آنچه آماده نیست، تصمیم‌های سازمان شماست.

تصمیم‌هایی که پیش از استقرار باید گرفته شوند

1. تعریف داده: «فروش»، «مشتری فعال» و «بهای تمام‌شده» برای سازمان شما یعنی چه؟

2. مالکیت داده: چه کسی پاسخگوی درستی هر دادهٔ پایه است؟

3. مراکز هزینه و ساختار تحلیلی: مدیر برای تصمیم به چه تفکیکی از عددها نیاز دارد؟

4. حق تصمیم و سطوح تأیید: چه کسی چه چیزی را و تا چه سقفی تأیید می‌کند؟

5. فرایند مطلوب: نه فرایند امروز، بلکه فرایندی که باید باشد.

6. شاخص‌های عملکرد: کدام شاخص کنار کدام شاخص سنجیده می‌شود تا دستکاری نشود؟

پیکربندی، سفارشی‌سازی یا یکپارچه‌سازی؟

راه	کی مناسب است	خطر
استفادهٔ استاندارد	فرایند شما با روش استاندارد اودو فرق اساسی ندارد	کمترین خطر؛ اولویت اول
پیکربندی	نیاز با تنظیمات موجود پاسخ می‌گیرد	تنظیماتی که کسی دلیلش را نمی‌داند
سفارشی‌سازی	نیاز مزیت رقابتی واقعی شماست	هزینهٔ نگهداری و ارتقاء؛ گاهی فقط عادت قدیمی را حفظ می‌کند
یکپارچه‌سازی	سامانهٔ دیگری باید بماند	دو منبع برای یک داده؛ نیاز به تعریف دقیق مالکیت

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

نرم‌افزارفروش یا معمار کسب‌وکار؟

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

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

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

مسیر سیستم‌سازی در دیباگ: از تشخیص تا تثبیت

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

1. شناخت وضع موجود: فرایندها، داده‌ها و نقش‌ها همان‌طور که واقعاً اجرا می‌شوند، نه آن‌طور که روی کاغذ نوشته شده‌اند.

2. شکاف‌ها و گلوگاه‌ها: کجا کار می‌ماند، تکرار می‌شود یا به یک نفر وابسته است؟

3. ریشه‌یابی چهارلایه: هر مشکل ریشه در کدام لایه دارد: داده، ساختار، فرایند یا انسان؟

4. طراحی وضع مطلوب: فرایندها، حق تصمیم و تعریف داده‌ها آن‌طور که باید باشند.

5. کنترل‌ها و شاخص‌ها: کنترل برای نقاط پرخطر، شاخص‌هایی که رفتار را خراب نکنند.

6. نیازمندی‌های اودو: هر نیاز مشخص می‌شود که استاندارد است، پیکربندی است، سفارشی‌سازی یا یکپارچه‌سازی.

7. استقرار اودو: بر پایهٔ طراحی، نه بر پایهٔ عادت‌های قدیمی.

8. تثبیت و بهبود مستمر: آموزش، پیگیری پذیرش و بازبینی شاخص‌ها تا سیستم در عمل زنده بماند.

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

پرسش‌های رایج

سیستم‌سازی سازمان چقدر طول می‌کشد؟

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

آیا بدون سیستم‌سازی هم می‌شود اودو را مستقر کرد؟

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

حاکمیت داده برای شرکت‌های کوچک و متوسط هم لازم است؟

بله، اما سبک. برای شروع همین کافی است که چند عدد کلیدی، مثل فروش و بهای تمام‌شده، یک تعریف و یک مسئول داشته باشند.

تفاوت مشاور سیستم‌سازی با شرکت پیاده‌ساز ERP چیست؟

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

اگر ERP داریم و جواب نداده، از کجا شروع کنیم؟

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

گام بعد: مشاورهٔ رایگان سیستم‌سازی و دموی اودو

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

دریافت مشاورهٔ رایگان سیستم‌سازی و دموی اودو

منابع

1. عوامل شکست پیاده‌سازی ERP در ایران، فصلنامهٔ مدیریت فناوری اطلاعات، دانشگاه تهران: jitm.ut.ac.ir/article_63108.html

2. DAMA International (2017). DAMA-DMBOK: Data Management Body of Knowledge, 2nd ed. Technics Publications.

3. Khatri, V., & Brown, C. V. (2010). Designing data governance. Communications of the ACM, 53(1), 148–152.

4. Abraham, R., Schneider, J., & vom Brocke, J. (2019). Data governance: A conceptual framework, structured review, and research agenda. International Journal of Information Management, 49, 424–438.

5. Romney, M. B., Steinbart, P. J., Summers, S. L., & Wood, D. A. (2021). Accounting Information Systems, 15th Global ed. Pearson.

6. Meadows, D. H. (2008). Thinking in Systems: A Primer. Chelsea Green.

7. Sterman, J. D. (2000). Business Dynamics: Systems Thinking and Modeling for a Complex World. McGraw-Hill.

8. Campbell, D. T. (1979). Assessing the impact of planned social change. Evaluation and Program Planning, 2(1), 67–90.