در بسیاری از سازمانها، گفتگو درباره مدیریت فرآیند با سؤال «کدام نرمافزار را بخریم؟» آغاز میشود. تیم فناوری چند BPMS را بررسی میکند، دمو میبیند و قابلیتهایی مانند فرمساز، گردش کار و گزارش را مقایسه میکند. با این حال، هنوز مشخص نیست کدام فرآیند اولویت دارد، مالک آن چه کسی است، چه مشکلی باید حل شود و موفقیت با چه شاخصی سنجیده خواهد شد.
در نقطه مقابل، بعضی سازمانها ماهها فرآیندها را مدل میکنند، اما مدلی برای اجرا، ثبت رخداد و پایش واقعی ندارند. نمودارها تهیه میشوند، ولی کار همچنان با ایمیل، اکسل و پیگیری شخصی جلو میرود. این دو وضعیت از یک ابهام مشترک میآیند: یکیدانستن BPM و BPMS.
BPM و BPMS رقیب یا جایگزین یکدیگر نیستند. BPM پاسخ میدهد فرآیند چگونه باید مدیریت و بهبود یابد؛ BPMS کمک میکند بخشی از این طراحی در محیط عملیاتی اجرا، کنترل و اندازهگیری شود. بدون BPM، ابزار ممکن است آشفتگی موجود را مکانیزه کند؛ بدون بستر اجرا نیز بهبود فرآیند ممکن است کند، دستی و کمردیابی باقی بماند.
تفاوت BPM و BPMS دقیقاً چیست و چه مرزی دارد؟
BPM مخفف Business Process Management و به معنای مدیریت فرآیندهای کسبوکار است. BPM یک رویکرد مدیریتی و سازمانی است که فرآیندها را بهعنوان داراییهای قابل طراحی، مالکیت، سنجش و بهبود میبیند. دامنه آن از معماری فرآیند و حاکمیت تا تحلیل، بازطراحی، اجرا، پایش و بهبود مستمر امتداد دارد.
BPMS مخفف Business Process Management System یا Suite است. BPMS یک بستر نرمافزاری برای مدلسازی اجرایی، ساخت فرم، تعریف قواعد، تخصیص کار، یکپارچهسازی با سامانهها، مدیریت دسترسی، ثبت رخدادها و پایش فرآیند است.
مرز ساده چنین است: BPM تعیین میکند چه چیزی، چرا، با چه مالکیتی و با چه معیار نتیجهای مدیریت شود؛ BPMS مشخص میکند گردش کار چگونه در نرمافزار اجرا و ردیابی شود. انتخاب BPMS بخشی از برنامه BPM است، نه نقطه شروع یا معادل آن.
موضوع مقایسه | BPM | BPMS |
ماهیت | رویکرد و قابلیت مدیریتی سازمان | بستر نرمافزاری اجرای فرآیند |
تمرکز | ارزش، مالکیت، عملکرد و بهبود | گردش کار، قواعد، داده و یکپارچهسازی |
پرسش اصلی | کدام فرآیند را چرا و چگونه بهبود دهیم؟ | فرآیند چگونه اجرا، کنترل و ثبت شود؟ |
خروجی | معماری، حاکمیت، مدل To-Be، KPI و Backlog | فرم، Workflow، Rule، اتصال و داشبورد عملیاتی |
نقشهای محوری | مالک فرآیند، مدیر عملیات، تیم BPM و تحول | تیم محصول، تحلیلگر، توسعه، IT و پشتیبانی |
معیار موفقیت | کاهش زمان، خطا، هزینه و ریسک؛ افزایش کیفیت | پذیرش، پایداری، SLA، رهگیری و عملکرد فنی |
بدون دیگری | میتواند دستی آغاز شود اما مقیاس محدود است | ممکن است اجرا شود اما ابزارمحوری و اتوماسیون وضع موجود محتمل است |
مسئله سازمانی پشت این موضوع؛ سازمان نرمافزار میخرد اما مدل مدیریت فرآیند ندارد
خرید BPMS معمولاً تصمیم ملموستری از ساخت قابلیت BPM به نظر میرسد: بودجه، محصول، پیمانکار و برنامه تحویل مشخصاند. اما بخش دشوارتر—توافق درباره مرز فرآیند، مالک، اختیار، استثنا، داده، KPI و تغییر نقشها—ممکن است به بعد موکول شود.
در این وضعیت، نیازمندیها به فهرست فرمها و تأییدها تقلیل پیدا میکنند. هر واحد میخواهد مسیر فعلی خود را عیناً وارد نرمافزار کند. نتیجه، گردش کاری طولانی با همان کنترلهای تکراری، نقشهای مبهم و دادههای ناسازگار است؛ فقط این بار تأخیرها در یک سامانه جدید رخ میدهند.
نشانههای ابزارمحوری عبارتاند از:
• انتخاب محصول پیش از تعیین فرآیندهای اولویتدار؛
• نبود مالک کسبوکاری و پاسخگویی کامل پروژه توسط IT؛
• تعریف موفقیت با تعداد فرم یا Workflow تحویلشده؛
• نبود خط مبنا برای زمان، کیفیت، خطا و SLA؛
• مکانیزهکردن همه تأییدها بدون بررسی ارزش آنها؛
• توقف بهبود پس از راهاندازی نرمافزار.

BPM بهعنوان رویکرد مدیریتی
BPM با شناخت فرآیندهای انتهابهانتها آغاز میشود. یک فرآیند ممکن است از درخواست مشتری شروع شود، از چند واحد عبور کند و با تحویل خدمت و دریافت نتیجه پایان یابد. ساختار واحدها مهم است، اما فرآیند باید از دید ارزش ایجادشده و نتیجه نهایی دیده شود.
اجزای اصلی یک مدل BPM عبارتاند از:
• معماری فرآیند: مشخصکردن فرآیندهای اصلی، پشتیبان و مدیریتی و ارتباط آنها با زنجیره ارزش؛
• حاکمیت: تعیین مالک فرآیند، اختیار تصمیم، نقش تیم BPM و سازوکار حل تعارض؛
• تحلیل و بازطراحی: شناخت وضعیت موجود، حذف اتلاف، مدیریت استثنا و طراحی To-Be؛
• اندازهگیری: تعریف KPI، خط مبنا، هدف، SLA و شواهد عملکرد؛
• بهبود مستمر: ثبت مسئلهها در Backlog، اجرای تغییر و سنجش اثر.
BPM الزاماً با نرمافزار شروع نمیشود. سازمان میتواند ابتدا مرز فرآیند، نقشها و شاخصها را روشن کند، یک رویه را سادهسازی کند یا تعداد تأییدها را کاهش دهد. ارزش این اقدامات در این است که مسئله پیش از مکانیزاسیون حل یا دستکم دقیق تعریف شود.
همچنین BPM فقط مدلسازی BPMN نیست. نمودار زبان توصیف است، اما مدیریت فرآیند به تصمیم درباره مسئولیت، عملکرد، داده، ریسک و تغییر رفتاری نیز نیاز دارد.
BPMS بهعنوان بستر اجرا و پایش
BPMS مدل فرآیند را به یک جریان عملیاتی تبدیل میکند. درخواست در سامانه ثبت میشود، نقش بعدی بر اساس قواعد تعیین میگردد، داده از منابع مرتبط خوانده میشود، مهلتها پایش میشوند و تاریخچه اقدامات برای گزارش و ممیزی باقی میماند.
قابلیتهای رایج BPMS شامل موارد زیر است:
• مدلسازی فرآیند و تبدیل مدل به Workflow اجرایی؛
• فرمساز و مدیریت دادههای پرونده؛
• موتور قواعد کسبوکار و مسیریابی شرطی؛
• کارتابل، اعلان، زمانبندی و مدیریت SLA؛
• یکپارچهسازی با ERP، CRM، پرتال و سرویسهای سازمانی؛
• کنترل دسترسی، ثبت تاریخچه و قابلیت ممیزی؛
• داشبورد عملیاتی و داده لازم برای تحلیل گلوگاهها.
BPMS بیشترین ارزش را در فرآیندهای پرتکرار، بینواحدی، دارای قواعد مشخص، نیازمند رهگیری و وابسته به چند سامانه ایجاد میکند. با این حال، برای فرآیند بسیار ناپایدار یا مسئلهای که هنوز درباره قواعد آن توافق نشده، توسعه زودهنگام میتواند دوبارهکاری ایجاد کند.
زمان نیاز به هرکدام و خطای ابزارمحوری
پرسش درست این نیست که «BPM یا BPMS؟». مسیر معمول چنین است: ابتدا با BPM مسئله، مالک، معماری، اولویت و معیار ارزش روشن میشود؛ سپس BPMS برای اجرای فرآیندهای مناسب و تولید داده عملیاتی به کار میرود؛ داده اجرا نیز دوباره به چرخه بهبود BPM بازمیگردد.
سازمان در این شرایط ابتدا به BPM نیاز فوری دارد: فرآیندها مرز روشنی ندارند، واحدها درباره مسئولیت اختلاف دارند، KPI و خط مبنا وجود ندارد یا هنوز مشخص نیست چه چیزی باید مکانیزه شود. در مقابل، زمانی که فرآیند نسبتاً پایدار، پرتکرار و قابل تعریف است و پیگیری دستی، تأخیر یا نبود رهگیری مسئله ایجاد کرده، BPMS میتواند اهرم اجرا باشد.
سؤال آمادگی | اگر پاسخ «خیر» است | اقدام پیش از توسعه |
مسئله و نتیجه مورد انتظار روشن است؟ | خطر اتوماسیون بدون ارزش | تعریف مسئله و KPI نتیجه |
مالک انتهابهانتها تعیین شده است؟ | توقف تصمیم میان واحدها | تعیین مالک و حدود اختیار |
فرآیند To-Be و استثناها مرور شدهاند؟ | انتقال آشفتگی به نرمافزار | بازطراحی و آزمون سناریوها |
داده و منبع معتبر مشخصاند؟ | ورود دوباره و مغایرت اطلاعات | تعریف داده، مالک و یکپارچهسازی |
معیار پذیرش و بهرهبرداری وجود دارد؟ | تحویل فنی بدون نتیجه | خط مبنا، هدف، آموزش و پایش |
خطای ابزارمحوری با یک سؤال ساده قابل تشخیص است: اگر نام محصول را از طرح پروژه حذف کنیم، آیا هنوز مسئله، فرآیند هدف، مالک، نتیجه و معیار موفقیت روشناند؟ اگر پاسخ منفی است، سازمان هنوز آماده انتخاب یا توسعه BPMS نیست.

مثال سازمانی و سناریوی کاربرد
فرض کنیم درخواست خرید در یک سازمان از فرم کاغذی آغاز میشود، سه سطح تأیید دارد، استعلامها با ایمیل انجام میشوند و وضعیت پرونده در اکسل پیگیری میشود. مدیریت تصمیم میگیرد BPMS تهیه کند تا فرایند را مکانیزه کند.
اگر مسیر موجود عیناً پیاده شود، فرم دیجیتال میشود اما سه تأیید، ابهام حدود اختیار، ورود تکراری کد کالا و انتظار برای اطلاعات مالی باقی میمانند. سازمان نرمافزار دارد، ولی نتیجه کسبوکاری تغییر زیادی نکرده است.
با رویکرد BPM، ابتدا مشخص میشود هدف کاهش زمان چرخه و افزایش قابلیت کنترل تعهدات است. تحلیل نشان میدهد یکی از تأییدها ارزش کنترلی مستقلی ندارد، حدود مبلغ میتواند مسیر تأیید را تغییر دهد و داده تأمینکننده باید از منبع معتبر خوانده شود. مالک فرآیند، KPI و استثناها نیز تعیین میشوند.
سپس BPMS فرم، قواعد مبلغ، کارتابل نقشها، اتصال به سامانه مالی، هشدار SLA و داشبورد زمان چرخه را اجرا میکند. در این سناریو، BPM فرآیند درستتر را طراحی کرده و BPMS آن را با قابلیت رهگیری و اندازهگیری به عملیات تبدیل کرده است.
اشتباهات رایج و گام بعدی پیشنهادی
نخستین اشتباه، استفاده از BPM و BPMS بهعنوان دو نام برای یک مفهوم است. این ابهام باعث میشود پروژه نرمافزار جای برنامه مدیریت فرآیند بنشیند. اشتباه دوم، فرض این است که اتوماسیون همیشه معادل بهبود است؛ فرآیند پیچیده میتواند پس از اتوماسیون نیز پیچیده باقی بماند.
اشتباه سوم، سپردن کامل پروژه به IT است. فناوری مسئول معماری فنی، امنیت، یکپارچهسازی و پایداری است؛ اما مالک کسبوکاری باید درباره هدف، قواعد، استثنا و نتیجه پاسخگو باشد. اشتباه چهارم نیز انتخاب دامنه بزرگ و تلاش برای مکانیزهکردن همه فرآیندها در یک موج است.
برای شروع با دامنه محدود، یک فرآیند پرتکرار و قابل سنجش را انتخاب کنید که مالک فعال، مسئله روشن و وابستگی فنی قابل مدیریت داشته باشد. ابتدا خط مبنا و To-Be را تثبیت کنید، سپس یک نسخه محدود را اجرا و اثر آن را بسنجید.
گام بعدی: پس از روشنشدن تفاوت مدیریت فرآیند و ابزار اجرا، سازمان باید توالی اقدامات، معماری فرآیند، اولویت مکانیزاسیون و مدل حاکمیت را مشخص کند. ادامه مسیر، مطالعه «نقشه راه BPM؛ از معماری فرآیند تا بهبود مستمر» است.
جمعبندی؛ BPM جهت میدهد و BPMS اجرای قابل کنترل میسازد
BPM یک قابلیت مدیریتی برای شناخت، طراحی، مالکیت، اندازهگیری و بهبود فرآیندهاست. BPMS بستری است که مدل منتخب را به فرم، گردش کار، قواعد، اتصال، کنترل دسترسی و داده قابل پایش تبدیل میکند.
سازمان میتواند BPM را بدون BPMS آغاز کند، اما برای مقیاس، رهگیری و اجرای فرآیندهای مناسب به فناوری نیاز خواهد داشت. در مقابل، خرید BPMS بدون BPM ممکن است خروجی فنی تولید کند، اما الزاماً ارزش عملیاتی یا بهبود پایدار نمیسازد.
در یک جمله: BPM مشخص میکند چه فرآیندی را چرا و چگونه مدیریت کنیم؛ BPMS کمک میکند همان فرآیند را در مقیاس واقعی اجرا، کنترل و اندازهگیری کنیم.
سؤالات متداول
آیا BPM همان نرمافزار BPMS است؟
خیر. BPM رویکرد مدیریتی و سازمانی است؛ BPMS نرمافزار پشتیبان اجرا و پایش فرآیند است. ابزار یکی از توانمندسازهای BPM محسوب میشود.
آیا میتوان BPM را بدون خرید BPMS آغاز کرد؟
بله. معماری فرآیند، تعیین مالک، بازطراحی، تعریف KPI و بهبود رویهها میتوانند پیش از خرید ابزار انجام شوند. این کار ریسک انتخاب و توسعه نادرست را کاهش میدهد.
مهمترین ریسک خرید BPMS پیش از آمادگی سازمان چیست؟
مکانیزهشدن فرآیند نامناسب، افزایش هزینه تغییر، تعارض میان واحدها و سنجش موفقیت با تحویل فنی بهجای نتیجه کسبوکاری مهمترین ریسکها هستند.
برای پایلوت BPMS چه فرآیندی مناسب است؟
فرآیندی پرتکرار، بینواحدی، دارای مسئله قابل اندازهگیری، مالک فعال، قواعد نسبتاً پایدار و دامنه فنی قابل مدیریت گزینه مناسبتری برای پایلوت است.





دیدگاهها
نظر یا پرسش خود را درباره این مقاله ثبت کنید.