نرم افزار مدیریت فرآیند چیست و چه تفاوتی با اتوماسیون اداری دارد؟

BPMS مخفف Business Process Management System است. یک BPMS واقعی معمولاً باید بتواند حداقل بخش مهمی از چرخه طراحی، اجرا، پایش و اصلاح فرآیند را مدیریت کند.

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

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

استاندارد BPMN نیز به همین دلیل اهمیت پیدا می‌کند. BPMN یک استاندارد رسمی OMG برای مدل‌سازی فرآیندهای کسب‌وکار است و می‌تواند زبان مشترکی میان تحلیلگر کسب‌وکار و تیم فنی ایجاد کند. (استاندارد BPMN در OMG)

البته داشتن BPMN به‌تنهایی یک نرم‌افزار را مناسب سازمان شما نمی‌کند. در یک کسب‌وکار کوچک ممکن است سادگی Form Builder و Workflow از پشتیبانی کامل ده‌ها Element استاندارد BPMN مهم‌تر باشد. در مقابل، در یک سازمان بزرگ که ده‌ها فرآیند پیچیده و چند تیم توسعه دارد، استاندارد بودن مدل‌ها می‌تواند اهمیت بیشتری پیدا کند.

همچنین باید BPMS را از ابزارهای Integration Automation مانند n8n و از نرم‌افزارهای صرفاً مدل‌سازی مانند Bizagi Modeler تفکیک کرد. هر سه ارزشمندند، اما مسئله متفاوتی را حل می‌کنند.

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

قبل از مقایسه نرم‌افزارها: «رایگان» دقیقاً یعنی چه؟

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

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

گاهی محصول واقعاً Community Edition متن‌باز دارد و می‌توانید آن را روی سرور خود نصب کنید. Joget DX Community برای مثال تحت GPLv3 عرضه می‌شود. (مستندات رسمی Joget)

گاهی هسته نرم‌افزار Open Source است اما امکانات Enterprise، امنیت پیشرفته، High Availability یا پشتیبانی رسمی هزینه دارد.

گاهی استفاده غیرعملیاتی بدون هزینه لایسنس مجاز است، اما اجرای عملیاتی مجوز تجاری می‌خواهد؛ اجزای اصلی Camunda 8 از نسخه 8.6 به بعد نمونه‌ای از این تفاوت هستند. (مجوزهای Camunda 8)

و گاهی فقط ابزار طراحی رایگان است. Bizagi Modeler اجازه می‌دهد فرآیندها را به‌صورت رایگان مدل، مستند و شبیه‌سازی کنید، اما این موضوع را نباید با اجرای رایگان اتوماسیون سازمانی اشتباه گرفت. (Bizagi Modeler)

بنابراین اولین سؤال هنگام دیدن عبارت «Free» این نیست که «رایگان است یا نه؟» بلکه باید بپرسید:

معرفی نرم افزار مدیریت فرآیند خارجی و رایگان

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

معرفی نرم افزارهای مدیریت فرآیند ایرانی

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

ولی این مزایا نباید باعث شوند معماری، API، مقیاس‌پذیری یا وابستگی به فروشنده بررسی نشود.

جدول مقایسه نرم افزار مدیریت فرآیند

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

در موبایل، جدول را به چپ و راست بکشید. «قابل بررسی» به معنی تأیید عملکرد محصول در سازمان شما نیست.

بهترین نرم افزار مدیریت فرآیند را چگونه انتخاب کنیم؟

سؤال «بهترین BPMS چیست؟» بدون اطلاعات بیشتر تقریباً شبیه سؤال «بهترین خودرو چیست؟» است.

بهترین برای چه کاری؟

BPMS مناسب یک بیمارستان ۱۰۰۰ نفره لزوماً برای فروشگاهی با ۲۰ نفر کارمند مناسب نیست.

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

چرا TCO از قیمت لایسنس مهم‌تر است؟

فرض کنید یک BPMS متن‌باز هیچ هزینه لایسنسی ندارد. هنوز ممکن است برای سرور، Backup، امنیت، طراحی فرآیند، توسعه Connector، آموزش، نگهداری، Upgrade، مانیتورینگ و رفع خطا هزینه کنید.

بنابراین معیار حرفه‌ای‌تر، Total Cost of Ownership یا TCO است.

به‌صورت ساده:

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

جدول وزنی پیشنهادی برای انتخاب

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

امتیاز نهایی از ۱۰۰: مجموعِ (امتیاز هر معیار ÷ ۵ × وزن درصدی آن). پیش‌نیازهای حیاتی مانند امنیت و امکان اتصال، شرط ورود به مقایسه‌اند؛ امتیاز بالا در سایر معیارها کمبود آن‌ها را جبران نمی‌کند.

این وزن‌ها عمومی‌اند. برای بیمارستان ممکن است Security بالاتر رود؛ برای SME سادگی و TCO؛ و برای کارخانه Integration اهمیت بیشتری پیدا کند.

معیار انتخاب BPMS برای بیمارستان، فروشگاه، شرکت و کارخانه

همین تفاوت‌ها نشان می‌دهد جدول Feature Comparison عمومی کافی نیست.

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

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

اما باید از ابتدا قرارداد برای آن طراحی شده باشد.

ممکن است Vendor مالک لایسنس باشد ولی یک System Integrator دیگر فرآیندها را طراحی، Integrationها را توسعه و سیستم را Rollout کند.

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

ولی قبل از امضا مشخص کنید چه کسی به محیط Admin دسترسی دارد، مالک Source Codeهای توسعه سفارشی کیست، API Documentation در اختیار چه کسی قرار می‌گیرد، Warranty نرم‌افزار با تغییرات Integrator چه می‌شود و در اختلاف بین دو شرکت مسئول Root Cause چه کسی است.

همچنین مستندات فنی، نسخه Source توسعه‌های سفارشی، Deployment Scriptها، Database Schemaهای اضافه‌شده و آموزش تیم داخلی باید جزو Deliverable باشد.

قراردادی که فقط «تحویل سامانه» را تعریف می‌کند، برای یک سیستم حیاتی کافی نیست.

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

نکته مهم این است که همه آمارهای شکست تحول سازمانی را نباید مستقیماً به پروژه BPMS نسبت داد. اما تحقیقات تحول دیجیتال، ERP و Change Management الگوهای مشترک مهمی نشان می‌دهند.

McKinsey در بررسی تحول‌های سازمانی گزارش کرده که کمتر از یک‌سوم پاسخ‌دهندگان، تحول سازمان خود را هم در بهبود عملکرد و هم در حفظ آن به‌عنوان موفق ارزیابی کرده‌اند. (پژوهش تحول سازمانی McKinsey)

BCG نیز در مطالعه‌ای بر ۷۰ پروژه و نظرسنجی از ۸۲۵ مدیر ارشد گزارش کرد حدود ۷۰٪ تحول‌های دیجیتال به اهداف تعریف‌شده خود نمی‌رسند و بر نقش رهبری، فرهنگ، حاکمیت، افراد و تکنولوژی تأکید کرد. (پژوهش تحول دیجیتال BCG)

این اعداد نباید تبدیل به شعار «۷۰ درصد همه پروژه‌های نرم‌افزاری شکست می‌خورند» شوند. نتیجه مفیدتر این است که فناوری به‌تنهایی تضمین‌کننده تغییر نیست.

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

کارمندی که ده سال کار را با تلفن و Excel انجام داده، الزاماً با دیدن یک Workflow جدید خوشحال نمی‌شود.

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

در ارزیابی آمادگی سازمان، عادت‌های کاری، ریسک ادراک‌شده و نگرانی کاربران درباره تغییر نقش‌ها را بررسی کنید.

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

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

حمایت واقعی مدیریت

حمایت مدیریت یعنی مدیرعامل در جلسه Kick-off عکس بگیرد و بعد ناپدید شود؟ خیر.

Prosci در مطالعات خود «حضور فعال و قابل مشاهده Sponsor» را مرتباً مهم‌ترین عامل موفقیت تغییر گزارش کرده است. در یکی از داده‌های منتشرشده، پروژه‌های دارای Sponsor بسیار مؤثر به‌مراتب بیشتر از پروژه‌های دارای Sponsor بسیار ضعیف به اهداف خود رسیده‌اند. (نقش حامی تغییر در Prosci)

در پروژه BPMS این موضوع بسیار ملموس است.

اگر مدیر بگوید «در سیستم ثبت کن، ولی همین الان در واتساپ هم برای من بفرست»، خودش Shadow Process ایجاد کرده است.

مکانیزه کردن فرآیند بد

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

اگر یک درخواست برای تأیید از هفت مدیر عبور می‌کند، دیجیتال کردن آن لزوماً آن را خوب نمی‌کند.

قبل از Automation بپرسید:

• آیا این مرحله واقعاً لازم است؟
• آیا اطلاعات دوباره وارد می‌شوند؟
• آیا تأیید مبتنی بر Risk می‌تواند جای تأیید همگانی را بگیرد؟
• آیا می‌توان بخشی را حذف یا خودکار کرد؟

هدف «Paperless کردن فرآیند بد» نیست.

هدف بهتر کردن کار است.

انتخاب پروژه بیش از حد بزرگ

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

تحقیقات معتبر مدیریت تغییر درباره شکست تحول سازمانی چه می‌گویند؟

چهار منبع زیر برای گفت‌وگوی تیم پروژه درباره مدیریت تغییر نقطه شروع مناسبی هستند.

جان کاتر بر فوریت تغییر، ائتلاف راهبر، چشم‌انداز روشن و تثبیت تغییر در فرهنگ سازمان تأکید می‌کند. (مقاله جان کاتر در HBR)

مطالعات McKinsey درباره Organizational Transformation نیز بر اجرای مجموعه‌ای هماهنگ از اقدامات، رهبری و حفظ Value در طول تحول تأکید دارند. (پژوهش تحول سازمانی McKinsey)

گزارش BCG با عنوان Flipping the Odds of Digital Transformation Success شش عامل شامل استراتژی روشن، تعهد رهبری از مدیرعامل تا مدیران میانی، استفاده از افراد توانمند، Agile Governance، پایش مؤثر و پلتفرم تکنولوژی و داده مناسب را برجسته می‌کند. (پژوهش تحول دیجیتال BCG)

پژوهش‌های Prosci نیز برای بخش People Side of Change، Sponsor، ارتباطات، مشارکت کارکنان و رویکرد ساختاریافته به Change Management کاربردی هستند. (نقش حامی تغییر در Prosci)

برای تیم پروژه، خروجی کاربردی این منابع باید یک برنامه مشخص برای حمایت مدیریت، ارتباط با کارکنان، آموزش و پایش پذیرش کاربران باشد.

اشتباهات رایج در خرید و استقرار نرم افزار مدیریت فرآیند

اولین اشتباه، تهیه RFP بر اساس Feature List است. سازمان ۱۵۰ قابلیت می‌نویسد و هر Vendor کنار آنها «دارد» می‌زند؛ در حالی که نحوه اجرای قابلیت‌ها مشخص نیست.

بهتر است بخشی از ارزیابی را Scenario-based کنید.

مثلاً بگویید:

«درخواست خرید بالای ۵۰۰ میلیون تومان ابتدا باید کنترل بودجه شود. در صورت نبود بودجه به واحد درخواست‌کننده بازگردد. در خرید اضطراری مسیر متفاوت طی شود. اگر مدیر تا ۲۴ ساعت پاسخ نداد Escalation انجام شود. اطلاعات تأمین‌کننده از ERP خوانده شود و Dashboard زمان چرخه را نمایش دهد.»

بعد از Vendor بخواهید همین سناریو را اجرا کند.

• اشتباه دوم، انتخاب صرفاً بر اساس قیمت است.
• اشتباه سوم، اتوماسیون ۲۰ فرآیند به‌صورت همزمان است.
• اشتباه چهارم، نداشتن Process Owner مشخص است.
• اشتباه پنجم، آموزش فقط در روز Go-live است.
• اشتباه ششم، بی‌توجهی به Data Migration و Integration است.
• اشتباه هفتم، نداشتن KPI قبل از پروژه است. اگر Cycle Time فعلی را اندازه نگرفته‌اید، بعداً چگونه ثابت می‌کنید پروژه بهتر شده است؟
• اشتباه هشتم، وابستگی کامل به Vendor است؛ به شکلی که هیچ‌کس داخل سازمان نمی‌داند فرآیند چگونه ساخته شده است.
• و اشتباه نهم، اعلام پایان پروژه در روز Go-live است.

Go-live پایان پروژه تغییر نیست؛ شروع مرحله Adoption است.

نقشه راه پیشنهادی استقرار BPMS

1. مسئله را قبل از محصول تعریف کنید

   سه تا پنج مشکل واقعی انتخاب کنید.

   برای مثال:

   درخواست خرید به‌طور متوسط ۹ روز طول می‌کشد.

   وضعیت درخواست برای متقاضی مشخص نیست.

   ۳۰٪ اطلاعات دوباره در نرم‌افزار دیگری وارد می‌شوند.

   اگر مسئله قابل اندازه‌گیری نیست، احتمالاً Success Criteria نیز مبهم خواهد بود.

2. معماری و محدودیت‌ها را مشخص کنید

   Cloud یا On-prem؟

   چه سیستم‌هایی باید متصل شوند؟

   چه اطلاعاتی حساس است؟

   چند کاربر Concurrent دارید؟

   چه SLAای لازم است؟

3. Shortlist بسازید

   به جای دمو گرفتن از ۲۰ محصول، سه تا پنج محصول را براساس Must-have Criteria انتخاب کنید.

4. Proof of Concept واقعی اجرا کنید

   Vendor نباید فقط Demo خودش را نشان دهد.

   یکی از فرآیندهای شما را در مقیاس کوچک بسازد.

5. Commercial و TCO را مقایسه کنید

   قیمت ۳ تا ۵ سال را محاسبه کنید؛ نه فقط Invoice اول را.

6. پایلوت یک فرآیند انتخاب کنید

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

7. Change Management را همزمان اجرا کنید

   Stakeholder Map، ارتباطات، آموزش، Championهای داخلی و Sponsor باید قبل از Go-live آماده باشند.

8. KPIها را پایش کنید

   بهبود را با داده نشان دهید.

9. بعد از اثبات، Scale کنید

   وقتی Pattern موفق ایجاد شد، Process Factory یا Center of Excellence کوچک ایجاد کنید تا توسعه فرآیندها از حالت پروژه‌ای و تصادفی خارج شود.

KPIهای موفقیت پروژه اتوماسیون فرآیند

برای هر فرآیند حداقل Baseline قبل از پروژه داشته باشید.

این KPI آخر مهم است. BPMS فقط نباید فرآیند امروز را اجرا کند؛ باید تغییر فردای آن را هم آسان کند.

برای گردآوری داده و مشاهده روندها، داشبورد مدیریتی و KPIهای فرآیند می‌تواند اطلاعات چند سامانه را در کنار هم قرار دهد.

چک‌لیست اجرایی انتخاب و استقرار BPMS

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

• ۳ تا ۵ مسئله واقعی کسب‌وکار قبل از انتخاب نرم‌افزار تعریف شده است.
• Process Owner هر فرآیند مشخص است.
• وضعیت As-Is فرآیند ثبت شده است.
• KPI و Baseline قبل از اتوماسیون داریم.
• Must-have و Nice-to-have جدا شده‌اند.
• تعداد کاربران و Concurrent Users مشخص است.
• Cloud/On-prem و الزامات امنیتی تعیین شده‌اند.
• ERP، CRM، HIS، POS، CMMS و سایر Integrationها فهرست شده‌اند.
• API و Documentation نرم‌افزار بررسی شده است.
• وضعیت واقعی License برای Production بررسی شده است.
• هزینه ۳ تا ۵ ساله TCO محاسبه شده است.
• Exit Strategy و ریسک Vendor Lock-in بررسی شده است.
• Demo بر اساس Scenario واقعی سازمان اجرا شده است.
• حداقل یک Proof of Concept انجام شده است.
• Sponsor مدیریتی فعال تعیین شده است.
• کاربران کلیدی از مرحله طراحی درگیر شده‌اند.
• برنامه آموزش فقط محدود به Go-live نیست.
• فرآیند Pilot مشخص شده است.
• SLA پشتیبانی به‌صورت عددی در قرارداد آمده است.
• مالکیت توسعه‌های سفارشی و Source مشخص است.
• انتقال دانش به تیم داخلی در قرارداد وجود دارد.
• KPIهای Adoption بعد از Go-live پایش می‌شوند.
• Shadow Processها مانند Excel و WhatsApp اندازه‌گیری می‌شوند.
• برنامه Rollback، Backup و Disaster Recovery وجود دارد.
• توسعه سایر فرآیندها فقط بعد از ارزیابی نتایج Pilot آغاز می‌شود.

جمع‌بندی: کدام نرم افزار مدیریت فرآیند برای شما مناسب‌تر است؟

اگر تیم فنی دارید و کنترل معماری و Open Source برایتان مهم است، Joget، Flowable، Bonita یا Activiti می‌توانند ارزش بررسی داشته باشند.

اگر Orchestration فنی و فرآیندهای بزرگ Enterprise دارید، Camunda ارزش بررسی دارد، ولی شرایط فعلی Production License باید در TCO لحاظ شود. (مجوزهای Camunda 8)

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

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

و اگر مسئله اصلی شما اتصال CRM، ERP، API، هوش مصنوعی و چند سیستم به یکدیگر است، ممکن است به Integration Automation مانند n8n در کنار BPMS نیاز داشته باشید.

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

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

سوالات متداول

منابع و مستندات

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

• استاندارد BPMN در OMG
• مستندات رسمی Joget
• مجوزهای Camunda 8
• Bizagi Modeler
• Flowable Open Source
• سیاست امنیت و نگهداری Bonita
• مخزن رسمی Activiti
• اعلام رسمی برند Decisions
• مجوز رسمی n8n
• وب‌سایت رسمی هیرا
• معرفی رسمی Graph BPMS
• محصولات رسمی آی‌کن
• پژوهش تحول سازمانی McKinsey
• پژوهش تحول دیجیتال BCG
• نقش حامی تغییر در Prosci
• مقاله جان کاتر در HBR