بسیاری از سازمانها پروژههای فرآیندی متعددی دارند: یک واحد فرمهای خود را مکانیزه میکند، واحد دیگر مدل BPMN تهیه میکند، تیم فناوری در حال انتخاب BPMS است و مدیریت نیز انتظار دارد زمان و هزینه فرآیندها کاهش پیدا کند. با این حال، این اقدامها لزوماً یک برنامه منسجم مدیریت فرآیند را شکل نمیدهند.
وقتی پروژهها بدون توالی و حاکمیت مشترک اجرا شوند، مدلها در پوشهها باقی میمانند، فرآیندهای کماهمیت زودتر مکانیزه میشوند، تعارضهای بینواحدی حل نمیشوند و هر پروژه معیار موفقیت متفاوتی دارد. ممکن است نرمافزار تحویل شود، اما سازمان همچنان نداند کدام فرآیندها حیاتیاند، مالک نتیجه چه کسی است و بهبود بعدی از کجا باید آغاز شود.
نقشه راه مدیریت فرآیندهای کسبوکار (BPM) این پراکندگی را به یک مسیر قابل مدیریت تبدیل میکند. نقشه راه فقط فهرست فرآیندهای قابل اتوماسیون نیست؛ تصویری از معماری فرآیند، سطح بلوغ، اولویتهای بهبود، نقشها، فناوری، داده، شاخصها و موجهای اجراست.
این مقاله یک چارچوب اجرایی ارائه میدهد تا مدیر تحول و مدیر عملیات بتوانند از شناخت وضع موجود به معماری فرآیند، Backlog اولویتدار، استقرار و در نهایت بهبود مستمر برسند.
هدف، دامنه و خروجی مورد انتظار از نقشه راه BPM
پیش از مدلسازی یا انتخاب ابزار باید مشخص شود نقشه راه قرار است چه مسئلهای را حل کند. هدف میتواند کاهش وابستگی فرآیندها به افراد، کوتاهکردن زمان چرخه، افزایش قابلیت رهگیری، کنترل تعهدات خدمت یا ایجاد مبنایی برای مکانیزاسیون باشد.
هدفهایی مانند «پیادهسازی BPM» یا «اتوماسیون فرآیندها» بیش از حد کلیاند. هدف مناسب باید به یک نتیجه کسبوکاری متصل باشد؛ برای مثال «کاهش زمان پاسخ به درخواست مشتری از ۱۰ روز به ۶ روز» یا «قابل رهگیریشدن وضعیت درخواستهای خرید برای متقاضی و مدیر فرآیند».
دامنه نیز باید روشن باشد. آیا نقشه راه کل سازمان را پوشش میدهد یا از یک زنجیره ارزش، حوزه عملیاتی یا خانواده فرآیندی آغاز میشود؟ چه فرآیندهایی در فاز اول بررسی میشوند؟ کدام سامانهها و واحدها درگیرند؟ چه محدودیتهایی در بودجه، زمان و ظرفیت تیم وجود دارد؟
خروجی مورد انتظار از یک نقشه راه BPM معمولاً شامل موارد زیر است:
• معماری سطحبالای فرآیندها و ارتباط آنها با زنجیره ارزش؛
• ارزیابی بلوغ مدیریت فرآیند و شکافهای اصلی؛
• فهرست فرآیندهای اولویتدار و منطق انتخاب آنها؛
• Backlog اقدامهای تحلیل، بازطراحی، استانداردسازی و مکانیزاسیون؛
• مدل حاکمیت شامل مالک فرآیند، تیم BPM و نقاط تصمیم؛
• موجهای اجرا، وابستگیها، منابع و معیارهای موفقیت؛
• چرخه پایش و بهبود مستمر پس از استقرار.
این خروجیها باید به تصمیم کمک کنند. اگر سند فقط تعداد زیادی نمودار فرآیند تولید کند اما نتواند بگوید چه چیزی، با چه ترتیبی و توسط چه کسی اجرا میشود، هنوز نقشه راه شکل نگرفته است.
پیشنیازها، ذینفعان و شواهد لازم
BPM ذاتاً بینواحدی است. یک فرآیند ممکن است از فروش آغاز شود، از اعتبارسنجی و مالی عبور کند و در عملیات به تحویل خدمت برسد. به همین دلیل نقشه راه را نمیتوان صرفاً در واحد IT یا یک واحد عملیاتی طراحی کرد.
حداقل نقشهای لازم عبارتاند از حامی ارشد، مدیر تحول یا دفتر BPM، مالکان فرآیند، نمایندگان واحدهای درگیر، تحلیلگران فرآیند، فناوری اطلاعات، داده و امنیت. حامی ارشد برای رفع تعارض و تخصیص منابع لازم است؛ مالک فرآیند نسبت به نتیجه انتهابهانتها پاسخگوست و فناوری اطلاعات امکانپذیری و یکپارچهسازی را بررسی میکند.
شواهد مورد استفاده نیز نباید به مصاحبه محدود شوند. زمانهای واقعی، حجم درخواست، نرخ برگشت، خطاها، شکایتها، SLA، مسیرهای استثنا، فرمها، دستورالعملها، گزارشهای سامانهای و تجربه کاربران باید کنار هم دیده شوند.
پیشنیازهای مهم شروع عبارتاند از:
• حامی اجرایی با اختیار تصمیم درباره تعارضهای بینواحدی؛
• مالک یا نماینده پاسخگو برای فرآیندهای در دامنه؛
• دسترسی به داده، سند، کاربران و سامانههای مرتبط؛
• توافق درباره دامنه، معیارهای ارزش و افق فاز اول؛
• ظرفیت تیم برای تحلیل، بازطراحی، پیادهسازی و مدیریت تغییر.
اگر سازمان هنوز مالک فرآیند، داده پایه یا معیار نتیجه ندارد، این موارد باید بهعنوان بخشی از موج آمادهسازی وارد نقشه راه شوند؛ نه اینکه نادیده گرفته شوند.
ارزیابی بلوغ و طراحی معماری فرآیند
ارزیابی بلوغ BPM نشان میدهد سازمان در چه سطحی از تعریف، مالکیت، استانداردسازی، اندازهگیری، فناوری و بهبود قرار دارد. هدف آن دادن یک امتیاز تزئینی نیست؛ باید مشخص کند کدام شکافها مانع اجرای موج بعدی هستند.
برای مثال، سازمانی که فرآیندها را مدل کرده اما مالک و KPI ندارد، با سازمانی که هنوز مرز فرآیندهای خود را نمیشناسد متفاوت است. در حالت اول شکاف اصلی حاکمیت و پایش است؛ در حالت دوم ابتدا باید معماری و زبان مشترک فرآیند شکل بگیرد.
معماری فرآیند تصویر سطحبالایی از فرآیندهای اصلی، پشتیبان و مدیریتی و ارتباط آنها با ارزش ایجادشده برای مشتری است. این معماری از غرقشدن تیم در جزئیات جلوگیری میکند و نشان میدهد هر فرآیند به کدام قابلیت، هدف یا خدمت متصل است.
بُعد بلوغ | سؤال ارزیابی | نشانه شکاف |
معماری فرآیند | آیا نقشه سطحبالای فرآیندها و ارتباط آنها وجود دارد؟ | مدلهای پراکنده و نامگذاریهای متفاوت |
حاکمیت | آیا مالک، اختیار و سازوکار تصمیم مشخص است؟ | تعارض بین واحدها و نبود پاسخگویی نهایی |
روش و استاندارد | آیا قواعد مشترک تحلیل و مدلسازی وجود دارد؟ | مدلهای غیرقابل مقایسه یا بیش از حد پیچیده |
اندازهگیری | آیا زمان، کیفیت، هزینه و SLA پایش میشوند؟ | تصمیمگیری مبتنی بر برداشت و نه داده |
فناوری | آیا ابزار با معماری، امنیت و یکپارچگی متناسب است؟ | فرمهای جزیرهای و دوبارهکاری اطلاعات |
بهبود مستمر | آیا بازنگری و Backlog بهبود فعال است؟ | پروژه پس از تحویل متوقف میشود |
خروجی این مرحله باید معماری فرآیند، ارزیابی بلوغ مبتنی بر شواهد، شکافهای اولویتدار و وابستگیهای مهم باشد. این اطلاعات پایه انتخاب فرآیند و طراحی موجهای اجراست.
انتخاب فرآیندهای اولویتدار و طراحی Backlog
همه فرآیندها را نمیتوان همزمان تحلیل یا مکانیزه کرد. اولویتبندی باید میان اثر کسبوکاری، شدت مسئله، آمادگی و پیچیدگی تعادل ایجاد کند. انتخاب صرفاً بر اساس درخواست پرصداترین واحد یا سادگی پیادهسازی، معمولاً سبد نامتوازنی ایجاد میکند.
اثر کسبوکاری میتواند شامل کاهش زمان، هزینه، ریسک، خطا یا بهبود تجربه مشتری باشد. شدت مسئله با حجم کار، تعداد شکایت، تأخیر یا دوبارهکاری سنجیده میشود. آمادگی به وجود مالک، داده، ثبات نسبی فرآیند و مشارکت واحدها مربوط است. پیچیدگی نیز تعداد واحدها، استثناها، یکپارچهسازیها و الزامات امنیتی را دربر میگیرد.
معیار | پرسش تصمیم | نمونه شواهد |
اثر | بهبود این فرآیند چه ارزشی ایجاد میکند؟ | زمان چرخه، هزینه، کیفیت، ریسک یا رضایت |
فوریت | ادامه وضع موجود چه هزینهای دارد؟ | شکایت، SLA نقضشده یا ریسک قانونی |
آمادگی | مالک، داده و مشارکت لازم وجود دارد؟ | حامی فعال، داده پایه و تیم در دسترس |
پیچیدگی | دامنه و وابستگی فنی چقدر است؟ | تعداد واحدها، استثناها و سامانهها |
قابلیت تکرار | آیا یادگیری آن برای فرآیندهای دیگر مفید است؟ | الگوی مشترک نقش، فرم یا یکپارچهسازی |
پس از انتخاب فرآیند، باید Backlog بهبود ساخته شود. Backlog فقط فهرست قابلیتهای نرمافزار نیست. هر مورد باید مسئله، فرضیه بهبود، خروجی، مالک، ارزش، وابستگی و معیار پذیرش داشته باشد.
اقلام Backlog میتوانند شامل شفافسازی مرز و نقش، حذف فعالیت بدون ارزش، کاهش تأییدها، استانداردسازی داده، تعریف SLA، بازطراحی تجربه کاربر، یکپارچهسازی سامانه یا مکانیزاسیون باشند. برخی مسائل پیش از ورود به BPMS با تصمیم مدیریتی یا اصلاح رویه حل میشوند.
یک الگوی ساده برای هر مورد Backlog چنین است: «برای [کاربر یا نقش]، مسئله [وضعیت فعلی] را با [تغییر پیشنهادی] اصلاح میکنیم تا [شاخص نتیجه] از [خط مبنا] به [هدف] برسد.»
استقرار، پایش و چرخه بهبود مستمر
استقرار BPM پایان پروژه نیست؛ آغاز بهرهبرداری واقعی است. پس از بازطراحی یا مکانیزاسیون، سازمان باید ببیند کاربران چگونه از فرآیند استفاده میکنند، چه استثناهایی ایجاد میشود و آیا شاخصهای نتیجه تغییر کردهاند.
استقرار موفق معمولاً چهار جریان همزمان دارد:
• تغییر فرآیند و نقش: اصلاح مسئولیتها، دستورالعملها و نقاط تصمیم؛
• پیادهسازی فنی: فرم، گردش کار، قواعد، یکپارچهسازی و سطح دسترسی؛
• آموزش و پذیرش: مشارکت کاربران کلیدی، آموزش سناریومحور و پشتیبانی اولیه؛
• اندازهگیری: ثبت خط مبنا و پایش زمان، کیفیت، حجم، SLA و تجربه کاربر.
شاخصها باید سه سطح را پوشش دهند: شاخص پیشرفت پروژه، شاخص پذیرش و شاخص عملکرد فرآیند. «تحویل گردش کار» پیشرفت است؛ «درصد پروندههایی که از مسیر جدید عبور میکنند» پذیرش و «کاهش زمان چرخه» نتیجه فرآیندی محسوب میشود.
چرخه بهبود مستمر میتواند با ریتم ماهانه یا فصلی اجرا شود: داده و بازخورد جمعآوری میشود، انحراف و گلوگاه تحلیل میشود، یک اقدام به Backlog افزوده میشود، تغییر محدود اجرا میگردد و اثر آن دوباره سنجیده میشود.
در این چرخه، مالک فرآیند مسئول نتیجه است، تیم BPM روش و تسهیلگری را فراهم میکند و تیم فناوری تغییرات فنی را اجرا میکند. جلسه بازنگری باید درباره انحراف، علت و تصمیم بعدی باشد؛ نه صرفاً گزارش تعداد درخواستها.
ریسکهای اجرا، نقاط کنترل و معیارهای موفقیت
نقشه راه BPM با چند ریسک تکرارشونده مواجه است. نخست، ابزارمحوری است: سازمان نرمافزار را انتخاب میکند اما مالک، معماری و معیار ارزش ندارد. دوم، دامنه بیش از حد بزرگ است: تلاش میشود همه فرآیندها در یک موج مدلسازی یا مکانیزه شوند. سوم، مدلسازی بدون اجراست؛ مدلها تهیه میشوند اما به تصمیم یا تغییر واقعی متصل نیستند.
ریسکهای دیگر شامل نبود داده خط مبنا، پیچیدهکردن مدلها، نادیدهگرفتن استثناها، مقاومت کاربران، وابستگی به پیمانکار و نبود برنامه بهرهبرداری است.
برای کنترل این ریسکها، نقاط تصمیم مشخص تعریف کنید:
• تأیید مسئله، مالک و خط مبنا پیش از تحلیل تفصیلی؛
• تأیید معماری و اولویت پیش از ورود فرآیند به Backlog اجرا؛
• مرور مدل با کاربران و مالک پیش از توسعه؛
• آزمون سناریوهای اصلی و استثناها پیش از راهاندازی؛
• سنجش پذیرش و نتیجه پیش از توسعه دامنه به فرآیندهای بعدی.
ریسک | علامت هشدار | نقطه کنترل |
ابزارمحوری | گفتوگو از قابلیت نرمافزار شروع میشود | تأیید مسئله، ارزش و معماری پیش از انتخاب ابزار |
دامنه بزرگ | افزایش مداوم فرآیندها و نیازمندیها | تثبیت موج اول و انتقال موارد جدید به Backlog |
نبود مالک | تصمیمها میان واحدها متوقف میشوند | تعیین مالک و اختیار پیش از طراحی To-Be |
پذیرش ضعیف | کاربران مسیر دستی یا موازی را ادامه میدهند | پایلوت، آموزش و سنجش استفاده واقعی |
بهبود بدون داده | موفقیت فقط با تحویل سیستم سنجیده میشود | ثبت خط مبنا و KPI پیش از استقرار |
موفقیت نقشه راه با تعداد مدلها یا تعداد فرآیندهای مکانیزهشده سنجیده نمیشود. معیار اصلی این است که فرآیندها قابل مشاهده، دارای مالک، قابل اندازهگیری و وارد چرخه تصمیم و بهبود شده باشند.
فازبندی، تحویلیها و مسیر اقدام بعدی
فازبندی باید بر اساس قابلیتهای لازم و یادگیری سازمان انجام شود، نه صرفاً تقسیم تقویم. یک مسیر عملی میتواند پنج موج داشته باشد:
موج اول؛ آمادهسازی و حاکمیت
تعیین حامی، تیم BPM، دامنه، روش مشترک، واژگان و معیارهای ارزش. خروجی این موج منشور برنامه و مدل تصمیمگیری است.
موج دوم؛ معماری و ارزیابی بلوغ
تهیه معماری سطحبالای فرآیند، ارزیابی بلوغ، شناسایی شکافها و تعیین وابستگیهای مهم. خروجی، تصویر مشترک از وضع موجود است.
موج سوم؛ پایلوت و Backlog اولویتدار
انتخاب یک یا دو فرآیند مهم و آماده، تحلیل وضع موجود، طراحی To-Be، تعریف KPI و ساخت Backlog. هدف، ایجاد نتیجه قابل مشاهده و یادگیری است.
موج چهارم؛ استقرار و توسعه قابلیت مشترک
پیادهسازی فرآیند، یکپارچهسازی، آموزش، پایش و ایجاد قابلیتهایی مانند داده مرجع، نقشهای مشترک و استانداردهای طراحی.
موج پنجم؛ مقیاس و بهبود مستمر
توسعه الگوهای موفق به فرآیندهای همخانواده، فعالکردن بازنگری دورهای و مدیریت مستمر Backlog بهبود.
موج | تحویلی کلیدی | معیار عبور |
آمادهسازی | منشور، دامنه، نقشها و روش | حامی، مالک و معیار ارزش تأیید شدهاند |
معماری و بلوغ | معماری فرآیند و نقشه شکاف | اولویتها و وابستگیها روشناند |
پایلوت | مدل As-Is و To-Be، KPI و Backlog | راهکار محدود و قابل سنجش آماده اجراست |
استقرار | فرآیند عملیاتی، آموزش و پایش | پذیرش و نتیجه اولیه قابل مشاهده است |
مقیاس و بهبود | الگوهای تکرارپذیر و چرخه بازنگری | بهبود به روال مدیریتی تبدیل شده است |
نقشه راه باید در بازههای مشخص بازنگری شود. تجربه پایلوت، ظرفیت تیم، تغییر اولویت کسبوکار و نتایج عملکرد ممکن است توالی فرآیندها را تغییر دهند. این بازنگری به معنای بیثباتی نیست؛ بخشی از مدیریت واقعبینانه برنامه است.
گام بعدی: پس از روشنشدن معماری، اولویتها و مدل حاکمیت، سازمان باید بررسی کند چه نوع BPMS با نیازهای مدلسازی، اجرا، یکپارچهسازی، امنیت و بهرهبرداری آن متناسب است. ادامه مسیر، مطالعه «راهنمای انتخاب BPMS برای سازمانهای متوسط و بزرگ» و درخواست ارزیابی اولیه است.
مثال سازمانی؛ از پروژههای پراکنده تا برنامه مشترک BPM
فرض کنیم سازمانی سه پروژه مستقل دارد: واحد منابع انسانی گردش مرخصی را مکانیزه میکند، تدارکات روی درخواست خرید کار میکند و فناوری اطلاعات در حال ارزیابی BPMS است. هر پروژه مدل، پیمانکار و معیار خودش را دارد.
با طراحی نقشه راه مشخص میشود درخواست خرید اثر بیشتری بر زمان، هزینه و کنترل دارد، اما پیش از مکانیزاسیون باید حدود اختیار، کدینگ داده و ارتباط با سامانه مالی روشن شود. گردش مرخصی سادهتر است و میتواند برای آزمون استاندارد فرم، نقش و تجربه کاربر بهعنوان پایلوت استفاده شود.
سازمان ابتدا معماری فرآیند و استاندارد مشترک را تصویب میکند. پایلوت مرخصی را برای یادگیری اجرا میکند، سپس قابلیتهای تکرارپذیر را در درخواست خرید به کار میبرد. مالک هر فرآیند، KPI و ریتم بازنگری مشخص میشود. اکنون پروژهها دیگر سه جزیره نیستند؛ بخشی از یک برنامه مشترک با توالی و منطق روشناند.
جمعبندی؛ نقشه راه BPM، مسیر ساخت قابلیت مدیریت فرآیند است
نقشه راه BPM سازمان را از پروژههای موردی به یک قابلیت پایدار میرساند. این مسیر با تعریف هدف و دامنه آغاز میشود، سپس حاکمیت و شواهد لازم را فراهم میکند، بلوغ و معماری فرآیند را میسنجد، فرآیندهای اولویتدار را انتخاب میکند و Backlog اجرا را میسازد.
استقرار نیز تنها زمانی کامل است که پذیرش، عملکرد و نتیجه پایش شوند و فرآیند وارد چرخه بازنگری و بهبود مستمر شود. فناوری بخش مهمی از این مسیر است، اما بدون مالک، معماری، داده و معیار ارزش نمیتواند جای مدیریت فرآیند را بگیرد.
در یک جمله: نقشه راه BPM مشخص میکند سازمان کدام فرآیندها را، با چه ترتیبی، تحت چه حاکمیتی و با چه معیارهایی از وضع موجود به جریانهای قابل ردیابی و قابل بهبود تبدیل میکند.
تفاوت BPM و BPMS چیست؟ مدیریت فرآیند یا ابزار اجرا
سؤالات متداول
نقشه راه BPM برای چه سازمانهایی مناسب است؟
برای سازمانهایی که چند پروژه مدلسازی یا مکانیزاسیون دارند، فرآیندهایشان بین واحدها پراکنده است، مالکیت و KPI روشن نیست یا میخواهند BPMS را بر مبنای اولویتهای واقعی انتخاب و مستقر کنند، نقشه راه BPM ضروری است.
مهمترین پیشنیاز اجرای نقشه راه BPM چیست؟
وجود حامی اجرایی، مالک فرآیند، دامنه محدود و دسترسی به شواهد عملکرد مهمترین پیشنیازها هستند. سازمان باید بپذیرد که BPM پروژه صرفاً فناوری نیست و به تصمیمهای بینواحدی نیاز دارد.
چه خطا یا ریسکی باید پیش از شروع کنترل شود؟
شروع از خرید ابزار، مدلسازی همه فرآیندها یا انتخاب دامنه بسیار بزرگ از رایجترین ریسکهاست. ارزش، مالک، خط مبنا و معیار پذیرش باید پیش از توسعه مشخص شوند.
برای شروع با دامنه محدود چه گامی پیشنهاد میشود؟
یک فرآیند پرتکرار با مسئله قابل اندازهگیری، مالک فعال، دامنه کنترلشده و وابستگی فنی قابل مدیریت انتخاب کنید. پایلوت را برای ایجاد نتیجه و یادگیری طراحی کنید، نه فقط نمایش قابلیت نرمافزار.
دیدگاهها
نظر یا پرسش خود را درباره این مقاله ثبت کنید.