تجربه من از طراحی و اجرای فرآیندهای سازمانی با BPMS

آنچه در اجرای واقعی فرآیندهای سازمانی آموخته‌ام

در تجربه طراحی و پیاده‌سازی فرآیندهای سازمانی، برای من روشن شده است که موفقیت یک پروژه BPMS فقط به کیفیت نمودار BPMN یا امکانات فنی سامانه وابسته نیست. پذیرش کاربران، سادگی مسیر اجرا، کیفیت داده‌ها و امکان اصلاح تدریجی فرآیند، تأثیر مستقیمی بر نتیجه دارند. بعضی نکاتی که در ادامه می‌آیند، حاصل مواجهه عملی من با کاربران، فرم‌ها، شروط مسیریابی و نیازهای متغیر سازمان‌ها هستند.

مقاومت اولیه کاربران همیشه به معنای مخالفت با فناوری نیست

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

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

به همین دلیل، مشارکت کاربران در مرحله شناخت وضعیت موجود و اجرای آزمایشی اهمیت زیادی دارد. مشاهده کار واقعی، گفت‌وگو با افرادی که هر روز فرآیند را اجرا می‌کنند و توضیح منطق تغییرات، معمولاً نتیجه بهتری از ابلاغ یک فرآیند آماده و از بالا به پایین ایجاد می‌کند.

فرآیند بهتر است با یک نسخه ساده و قابل استفاده آغاز شود

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

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

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

داده‌های مرجع فرم‌ها باید به‌صورت متمرکز مدیریت شوند

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

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

برای اجرای درست این الگو باید چند نکته رعایت شود: کاربران نباید مستقیماً به پایگاه داده دسترسی داشته باشند، پرس‌وجوها باید امن و پارامتری باشند، گزینه‌های غیرفعال به‌جای حذف کامل نگهداری شوند و مقدار ثبت‌شده هر پرونده در آینده نیز قابل فهم باقی بماند. همچنین برای داده‌های پرتکرار می‌توان از کش کنترل‌شده استفاده کرد تا وابستگی فرم به پایگاه داده باعث کندی سامانه نشود.

فرم خوب باید به اندازه همان مرحله اطلاعات بخواهد

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

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

شاخص‌های گزارش‌گیری باید پیش از اجرای فرآیند مشخص شوند

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

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

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