
اجرای آزمایشی فرایند در BPMS یکی از مراحل مهم پیش از عملیاتیسازی گسترده فرایند در سازمان است. در این مرحله، فرایند با کاربران واقعی و در شرایطی نزدیک به محیط عملیاتی اجرا میشود تا مشکلاتی که در تحلیل، طراحی یا تستهای فنی مشخص نشدهاند، شناسایی شوند. پایلوت فرایند به سازمان کمک میکند عملکرد گردش کار، تجربه کاربران، قوانین کسبوکار، فرمها، گزارشها و سناریوهای مختلف را پیش از استقرار نهایی ارزیابی کند. در این مقاله با نحوه برنامهریزی و اجرای پایلوت، انتخاب کاربران و سناریوهای تست، ثبت و تحلیل مشکلات، تست مجدد و معیارهای تصمیمگیری برای Go، Conditional Go یا No-Go آشنا میشوید.
در پروژههای بهبود و اتوماسیون فرایند، یکی از مهمترین مراحل پیش از عملیاتیسازی فرایند در سطح سازمان، اجرای آزمایشی فرایند (Pilot) است. حتی اگر فرایند بهدرستی تحلیل و طراحی شده باشد و پیادهسازی آن در BPMS نیز بدون خطای فنی انجام شده باشد، هنوز نمیتوان با اطمینان گفت که فرایند در شرایط واقعی سازمان نیز به همان شکل مورد انتظار اجرا خواهد شد.
اجرای آزمایشی این امکان را فراهم میکند که فرایند بهصورت محدود و کنترلشده، با حضور کاربران واقعی و در شرایط نزدیک به محیط عملیاتی اجرا شود. در این مرحله میتوان مشکلاتی را شناسایی کرد که ممکن است در تحلیل اولیه، طراحی فرایند یا حتی تستهای فنی نرمافزار قابل مشاهده نباشند. اجرای آزمایشی علاوه بر پیدا کردن خطاهای نرمافزاری اهداف زیر را نیز دنبال می کند:
- فرایند طراحیشده در عمل قابل اجرا است.
- کاربران میتوانند با آن کار کنند.
- اهداف مورد انتظار از بهبود و اتوماسیون فرایند نیز تا حد قابل قبول محقق میشوند.
چرا اجرای آزمایشی فرایند اهمیت دارد؟
در بسیاری از پروژههای اتوماسیون فرایند، تمرکز اصلی تیم پروژه بر طراحی، پیادهسازی و تست فنی سیستم است. با این حال، یک فرایند سازمانی فقط مجموعهای از فرمها و گردشکارها نیست. این فرایند با کاربران، واحدهای سازمانی، قوانین کسبوکار، سامانههای دیگر، گزارشها و شرایط واقعی کاری در ارتباط است. به همین دلیل ممکن است فرایندی که در محیط تست کاملاً صحیح به نظر میرسد، پس از استفاده توسط کاربران واقعی با مشکلاتی مانند موارد زیر مواجه شود:
- برخی سناریوهای واقعی در طراحی فرایند پیشبینی نشده باشند.
- کاربران در بعضی مراحل فرایند دچار ابهام شوند.
- قوانین کسبوکار در شرایط خاص بهدرستی اعمال نشوند.
- فرمها یا محاسبات اطلاعات مورد نیاز کاربران را پوشش ندهند.
- گزارشها و شاخصهای عملکرد اطلاعات مورد انتظار را ارائه نکنند.
- در برخی واحدها یا شعب، شرایط اجرای فرایند با شرایط واحد اصلی متفاوت باشد.
- حجم واقعی درخواستها باعث ایجاد گلوگاههایی شود که در تست اولیه مشاهده نشدهاند.
بنابراین اجرای آزمایشی، یک مرحله واسط میان پیادهسازی فرایند در BPMS و عملیاتیسازیگسترده آن در سازمان است که ریسک انتقال فرایند به محیط واقعی را کاهش میدهد.

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

چه چیزهایی؟
در اجرای آزمایشی نباید فقط گردش صحیح فرایند بررسی شود. بهتر است فرایند از چند جنبه مختلف ارزیابی شود:
- عملکرد فرایند و گردش کار
بررسی شود که فعالیتها، ارجاعها، تأییدها، بازگشتها و مسیرهای مختلف فرایند مطابق انتظار انجام میشوند.
- تجربه کاربری
بررسی شود که کاربران میتوانند فرمها و فعالیتهای خود را بدون ابهام انجام دهند و اطلاعات مورد نیاز آنها بهسادگی در دسترس است.
- قوانین کسبوکار و محاسبات
شرایط، قواعد، محاسبات و مسیرهای مختلف فرایند باید در سناریوهای متفاوت آزمایش شوند.
- خروجیها و گزارشها
گزارشها، داشبوردها و شاخصهای عملکردی مرتبط با فرایند نیز باید با دادههای واقعی یا دادههای آزمایشی واقعگرایانه بررسی شوند. همچنین میتوان شاخصهایی مانند زمان انجام فرایند، تعداد خطاها، تعداد برگشتها، زمان انتظار در مراحل مختلف و حجم درخواستهای قابل پردازش را بررسی کرد.
کجا؟
محل اجرای آزمایشی نیز میتواند بر نتیجه تأثیرگذار باشد. در سازمانهایی که دارای شعب یا واحدهای جغرافیایی مختلف هستند، بهتر است در صورت وجود تفاوت معنادار بین این واحدها، اجرای آزمایشی فقط در یک محل انجام نشود. همچنین باید شرایط واقعی دسترسی کاربران به سیستم مورد توجه قرار گیرد. برای مثال:
- کاربران از شبکه داخلی استفاده میکنند یا از خارج سازمان؟
- آیا دسترسی از طریق اینترنت یا VPN انجام میشود؟
- آیا کاربران از لپتاپ یا تبلت استفاده میکنند؟
- آیا فرمها و فعالیتها در اندازههای مختلف صفحه نمایش بهدرستی قابل استفاده هستند؟
- آیا کیفیت و سرعت شبکه در محلهای مختلف مناسب است؟
این موارد ممکن است در محیط کنترلشده تست شناسایی نشوند، اما هنگام استفاده واقعی از فرایند مشکل ایجاد کنند.
چه زمانی؟
زمان اجرای آزمایشی باید بهگونهای انتخاب شود که بتوان رفتار واقعی فرایند را مشاهده کرد. برای مثال، اجرای آزمایشی یک فرایند مالی در روزهای پایانی ماه یا سال ممکن است به دلیل حجم بالای فعالیتها شرایط غیرمعمولی ایجاد کند. از طرف دیگر، اجرای آزمایشی یک فرایند در یک بازه بسیار کوتاه نیز ممکن است فرصت مشاهده برخی سناریوهای واقعی را از بین ببرد.
بنابراین علاوه بر انتخاب زمان مناسب، باید مدت اجرای آزمایشی نیز مشخص شود. مدت پایلوت باید به اندازهای باشد که بتوان مسیرهای اصلی فرایند، شرایط استثنا، برگشت درخواستها، تأخیرها و سایر اتفاقاتی را که در چرخه واقعی فرایند رخ میدهند مشاهده کرد.

اجرای آزمایشی فرایند چگونه انجام میشود؟
پس از مشخص شدن کاربران، دامنه و زمان اجرای آزمایشی، میتوان اجرای پایلوت را در چند مرحله انجام داد.
- طراحی برنامه اجرای آزمایشی
در ابتدا باید مشخص شود که اجرای آزمایشی دقیقاً با چه هدفی انجام میشود. هدف میتواند شناسایی مشکلات فرایند، ارزیابی عملکرد فرایند بهبودیافته، بررسی تجربه کاربران یا اطمینان از صحت خروجیهای سیستم باشد. همچنین باید منابع مورد نیاز مشخص شوند. این منابع میتوانند شامل موارد زیر باشند:
- کاربران واحدهای مختلف
- کارشناسان کسبوکار
- مدیران و تأییدکنندگان
- کارشناسان فناوری اطلاعات
- تیم پیادهسازی فرایند
- BPMS و سایر سامانههای مرتبط
- تجهیزات و زیرساخت مورد نیاز
در این مرحله بهتر است معیارهای موفقیت اجرای آزمایشی نیز از قبل مشخص شوند. برای مثال:
- هیچ مشکل بحرانی در مسیرهای اصلی وجود نداشته باشد.
- تمام سناریوهای اصلی فرایند با موفقیت اجرا شوند.
- محاسبات و قوانین کسبوکار صحیح باشند.
- گزارشها و شاخصهای کلیدی عملکرد خروجی صحیح داشته باشند.
- کاربران اصلی بتوانند فرایند را بدون ابهام اجرا کنند.
- مشکلات باقیمانده مانع عملیاتیسازی فرایند نباشند.
تعیین این معیارها باعث میشود در پایان پایلوت، تصمیمگیری درباره عملیاتیسازی بر اساس شواهد انجام شود، نه صرفاً برداشتهای شخصی.
- طراحی سناریوهای تست و دادههای آزمایشی
در مرحله بعد باید مشخص شود چه سناریوهایی قرار است آزمایش شوند. سناریوها باید مسیرهای مختلف فرایند، از جمله مسیرهای عادی و استثنایی را پوشش دهند. برای مثال، فرض کنید در یک فرایند خرید، بر اساس مبلغ درخواست مسیرهای متفاوتی وجود دارد:
- درخواستهای کمتر از یک مبلغ مشخص بدون تأیید مدیریت ادامه پیدا میکنند.
- درخواستهای با مبلغ متوسط نیازمند تأیید مدیریت هستند.
- درخواستهای بالاتر از یک حد مشخص به کمیته معاملات ارجاع میشوند.
در این حالت، نمیتوان فقط یک درخواست با مبلغ متوسط را آزمایش کرد. باید دادههایی طراحی شود که تمام مسیرهای اصلی فرایند را فعال کنند.
برای مدیریت بهتر سناریوها میتوان جدولی مانند زیر تهیه کرد:
| مورد تست | هدف | سناریوی تست | نتیجه مورد انتظار | وضعیت |
| 1 | بررسی مسیر عادی | ثبت درخواست با مبلغ کمتر از حد تأیید | عبور مستقیم از مرحله تأیید مدیریت | موفق |
| 2 | بررسی تأیید مدیریت | ثبت درخواست با مبلغ متوسط | ارسال درخواست برای مدیر | موفق |
| 3 | بررسی مسیر کمیته | ثبت درخواست با مبلغ بالاتر از حد مشخص | ارجاع به کمیته معاملات | در حال تست |
استفاده از دادههای آزمایشی واقعگرایانه یا در صورت امکان، دادههای تاریخی باعث میشود نتیجه پایلوت به شرایط واقعی نزدیکتر باشد.
- اجرای سناریوها در محیط واقعی یا نزدیک به محیط عملیاتی
در این مرحله کاربران منتخب، سناریوهای تعیینشده را اجرا میکنند و تیم پروژه روند اجرای فرایند را زیر نظر میگیرد. بهتر است در طول اجرای آزمایشی، کاربران مشکلات خود را از طریق یک مسیر مشخص گزارش کنند. برگزاری جلسات کوتاه و منظم نیز میتواند برای بررسی مشکلات و تصمیمگیری درباره آنها مفید باشد. برای ثبت مشکلات میتوان از یک جدول مشترک آنلاین استفاده کرد که حداقل شامل اطلاعات زیر باشد:
| شماره | سناریو | تاریخ | شرح مشکل | دستهبندی | اهمیت | گزارشدهنده | اقدام اصلاحی | وضعیت |
| 1 | گزارشگیری | 10/06 | امکان فیلتر گزارش براساس تاریخ وجود ندارد | گزارش | متوسط | کاربر واحد مالی | اصلاح گزارش | در حال بررسی |
| 2 | ثبت درخواست | 11/06 | فیلد تاریخ مورد نیاز میتواند خالی باقی بماند | فرم | زیاد | کاربر واحد اداری | اصلاح اعتبارسنجی | اصلاح شد |
بهتر است مشکلات حذف نشوند، حتی اگر برطرف شده باشند. نگهداری تاریخچه مشکلات کمک میکند مشخص باشد چه مشکلی شناسایی شده، چه اقدامی برای آن انجام شده و آیا پس از اصلاح دوباره آزمایش شده است یا خیر.برای وضعیت مشکلات میتوان از چرخهای مانند زیر استفاده کرد:
ثبتشده ← در حال بررسی ← اصلاحشده ← نیازمند تست مجدد ← بستهشده
همچنین بهتر است شدت مشکلات بهصورت استاندارد مشخص شود، برای مثال:
- بحرانی
- زیاد
- متوسط
- کم
- تحلیل نتایج و اصلاح فرایند
پس از اجرای سناریوها، نتایج باید بررسی و دستهبندی شوند. همه مشکلات الزاماً با تغییر نرمافزار قابل حل نیستند. ممکن است یک مشکل ناشی از طراحی فرایند، یک قانون کسبوکار، فرم، گزارش، آموزش کاربر یا حتی یک رویه سازمانی باشد.
برای مثال، اگر کاربران در یک مرحله نمیدانند درخواست را به چه فردی ارجاع دهند، ممکن است مشکل اصلی در طراحی نقش سازمانی یا دستورالعمل فرایند باشد، نه در BPMS.
بنابراین در این مرحله باید مشخص شود که هر مشکل از چه نوعی است و چه اقدامی برای رفع آن لازم است:
- اصلاح طراحی فرایند
- اصلاح فرم
- اصلاح گردش کار
- اصلاح قوانین کسبوکار
- اصلاح محاسبات
- اصلاح گزارش یا داشبورد
- اصلاح تنظیمات BPMS
- آموزش کاربران
- تغییر رویه سازمانی
در صورتی که نتایج اجرای آزمایشی نشان دهد فرایند به اهداف مورد انتظار نمیرسد، ممکن است لازم باشد بخشی از فرایند دوباره طراحی و سپس در BPMS اصلاح شود.
- اجرای مجدد و تست دوباره
اجرای آزمایشی یک فعالیت یکباره نیست. اگر در طول پایلوت تغییر مهمی در فرایند، فرم، گردش کار یا قوانین کسبوکار ایجاد شود، بخشهای مرتبط باید دوباره آزمایش شوند.
برای مثال، اگر یک قانون جدید به فرایند اضافه شود که مسیر درخواستها را بر اساس مبلغ تغییر میدهد، فقط تست همان قانون کافی نیست. باید بررسی شود که تغییر ایجادشده روی مسیرهای دیگر فرایند نیز تأثیر منفی نگذاشته باشد. به همین دلیل بهتر است اجرای آزمایشی را یک چرخهبهبود و یادگیری در نظر بگیریم:
اجرا ←شناسایی مشکل ←تحلیل ←اصلاح ←تست مجدد ←ارزیابی
چه زمانی میتوان فرایند را عملیاتی کرد؟
در پایان اجرای آزمایشی باید درباره وضعیت فرایند تصمیمگیری شود. یکی از روشهای مناسب، استفاده از سه وضعیت است:
Go| آماده عملیاتیسازی
زمانی که:
- مسیرهای اصلی فرایند با موفقیت اجرا شدهاند.
- مشکل بحرانی یا مسدودکننده وجود ندارد.
- قوانین کسبوکار و محاسبات صحیح هستند.
- گزارشها و شاخصهای مورد نیاز درست کار میکنند.
- کاربران اصلی آمادگی استفاده از فرایند را دارند.
|Conditional Goعملیاتیسازی مشروط
زمانی که مشکلات باقیمانده اثر جدی بر اجرای فرایند ندارند و میتوان آنها را پس از عملیاتیسازی نیز در یک برنامه مشخص برطرف کرد. در این حالت باید مسئول، زمانبندی و نحوه پیگیری مشکلات باقیمانده مشخص شود.
|No-Go عدم آمادگی برای عملیاتیسازی
زمانی که مشکلات بحرانی وجود دارند، مسیرهای اصلی فرایند بهدرستی اجرا نمیشوند یا نتایج نشان میدهد که طراحی فعلی فرایند نیازمند بازنگری اساسی است. در چنین شرایطی ادامه دادن مسیر عملیاتیسازی میتواند باعث انتقال مشکلات به کاربران سازمان و افزایش هزینه اصلاح آنها پس از استقرار شود.
چکلیست اجرای آزمایشی فرایند
برای اطمینان از پوشش مناسب مراحل پایلوت میتوان از چکلیست زیر استفاده کرد:
| موضوع | سؤال کلیدی |
| هدف | آیا هدف اجرای آزمایشی مشخص شده است؟ |
| معیار موفقیت | آیا مشخص است که چه نتیجهای به معنی موفقیت پایلوت است؟ |
| کاربران | آیا نقشها و کاربران اصلی در پایلوت حضور دارند؟ |
| سناریوها | آیا مسیرهای عادی و استثنایی فرایند آزمایش شدهاند؟ |
| دادهها | آیا دادههای آزمایشی به شرایط واقعی نزدیک هستند؟ |
| فرمها | آیا فرمها نیازهای کاربران را پوشش میدهند؟ |
| قوانین | آیا قواعد کسبوکار و محاسبات بررسی شدهاند؟ |
| گزارشها | آیا گزارشها و شاخصهای عملکردی صحیح هستند؟ |
| زیرساخت | آیا شرایط دسترسی کاربران و شبکه بررسی شده است؟ |
| مشکلات | آیا تمام مشکلات ثبت و پیگیری میشوند؟ |
| تست مجدد | آیا اصلاحات دوباره آزمایش شدهاند؟ |
| تصمیم نهایی | آیا درباره Go،Conditional Go یا No-Go تصمیمگیری شده است؟ |
نتیجهگیری
اجرای آزمایشی فرایند یکی از مراحل مهم پیش از عملیاتیسازی فرایندهای بهبودیافته و اتوماسیونشده در BPMS است. این مرحله فرصتی ایجاد میکند تا فرایند نه فقط از نظر فنی، بلکه از منظر کاربران، شرایط واقعی اجرا، قوانین کسبوکار، خروجیها و اهداف سازمانی ارزیابی شود. تفاوت مهم اجرای آزمایشی با تست نرمافزار در این است که تست نرمافزار عمدتاً به دنبال اطمینان از صحت عملکرد سیستم است، در حالی که پایلوت باید مشخص کند آیا فرایند طراحیشده در شرایط واقعی سازمان نیز قابل اجرا و اثربخش است یا خیر.
یک اجرای آزمایشی موفق باید با هدف و معیارهای مشخص آغاز شود، کاربران و سناریوهای مناسب را پوشش دهد، مشکلات را بهصورت مستند ثبت و پیگیری کند و در صورت نیاز به اصلاح فرایند یا سیستم منجر شود. همچنین اجرای مجدد پس از اصلاحات، بخش مهمی از این چرخه است. در نهایت، خروجی پایلوت نباید صرفاً فهرستی از مشکلات باشد. مهمترین خروجی آن باید یک تصمیم مبتنی بر شواهد درباره آمادگی فرایند برای عملیاتیسازی باشد: آیا فرایند آماده است، با چند اصلاح جزئی میتواند عملیاتی شود یا پیش از استقرار نیازمند بازطراحی است؟
اگر این مرحله بهدرستی انجام شود، سازمان پیش از آنکه مشکلات فرایند را در مقیاس گسترده تجربه کند، فرصت شناسایی و اصلاح آنها را خواهد داشت و ریسک عملیاتیسازی فرایند در سطح سازمان کاهش پیدا میکند.
سوالات متداول
- زمان مطالعه: 22 دقیقه
- بازدید مقاله: 6 بازدید
- اشتراکگذاری:
- https://chargoon.com/?p=76898
- دریافت pdf

