یادداشتها و تجربهها
اهمیت فرآیندسازی در سازمان؛ از کنترل ریسک تا ارزیابی عملکرد با BPMS
فرآیندسازی فقط تبدیل فرمهای کاغذی به فرم آنلاین نیست. در این مقاله، با مثال فرآیند خرید، کنترل ریسکها، شاخصهای ارزیابی عملکرد و کاربرد دادههای BPMS در تصمیمگیری سازمانی آشنا میشوید.
یک درخواست خرید ثبت شده، اما کسی نمیداند چرا هنوز تأیید نشده است. واحد مالی میگوید مدارک ناقص بوده، متقاضی از این نقص خبر ندارد و مدیر هم فقط با پیگیری تلفنی میتواند وضعیت را بفهمد. مسئله صرفاً نبود نرمافزار نیست؛ مسیر کار، مسئولیتها و قواعد تصمیمگیری شفاف نیستند. فرآیندسازی در سازمان از همین نقطه شروع میشود: تبدیل کارهای پراکنده به مسیری روشن، قابل اجرا و قابل ارزیابی.
وقتی این مسیر در یک BPMS پیادهسازی شود، میتوان مشخص کرد چه کسی، چه کاری را، با چه اطلاعاتی و در چه زمانی انجام دهد. ارزش اصلی این کار فقط حذف کاغذ نیست؛ امکان کنترل ریسک، شناسایی گلوگاه و تصمیمگیری بر پایه دادههای واقعی اجرای کار است. البته هیچ نرمافزاری بهتنهایی مدیریت ضعیف یا فرآیند نامناسب را اصلاح نمیکند.
فرآیندسازی در سازمان چیست و چه تفاوتی با BPMS دارد؟
فرآیندسازی یعنی تعریف یک مسیر تکرارپذیر برای رسیدن به نتیجهای مشخص؛ مسیری که نقطه شروع، ورودی، خروجی، مسئول، قواعد و استثناهای آن معلوم باشد. برای مثال، فرآیند خرید از اعلام نیاز شروع میشود و بسته به دامنه تعریفشده میتواند تا دریافت کالا و تسویه ادامه داشته باشد.
BPM یا مدیریت فرآیندهای کسبوکار، رویکردی برای شناخت، تحلیل، اندازهگیری و بهبود مستمر این مسیرهاست. BPMS سامانهای است که از اجرای این رویکرد پشتیبانی میکند. در راهنمای مدیریت فرآیند IBM نیز تأکید بر کل مسیر کار و چرخه طراحی، اجرا، پایش و بهبود است؛ نه صرفاً مدیریت چند وظیفه جدا از هم.
BPMN با این دو متفاوت است: زبان استاندارد نمایش فرآیند است. مشخصات رسمی BPMN در OMG مرجع این استاندارد است. نمودار کمک میکند فعالیتها، رویدادها و مسیرهای تصمیمگیری قابل فهم شوند؛ اما یک نمودار بهتنهایی فرم اجرایی، کنترل دسترسی یا گزارش مدیریتی ایجاد نمیکند.
چرا الکترونیکیکردن فرمها کافی نیست؟
فرض کنید فرم کاغذی خرید به فرم آنلاین تبدیل شود، اما همچنان معلوم نباشد چه خریدی نیازمند تأیید مالی است، جانشین مدیر چه کسی است یا درخواست ناقص باید به کجا برگردد. در این حالت، ابهام قبلی فقط به محیط دیجیتال منتقل شده است.
پیش از ساخت فرم باید پاسخ این پرسشها روشن باشد: خروجی مورد انتظار چیست؟ صاحب فرآیند کیست؟ کدام تأیید واقعاً ضروری است؟ چه اطلاعاتی در هر مرحله لازم است؟ اگر کار متوقف شد، چه کسی باید اقدام کند؟ چه دادهای برای سنجش نتیجه نیاز داریم؟ پاسخ این پرسشها طراحی را از «فرمسازی» به «مدیریت جریان کار» تبدیل میکند.
فرآیندسازی چگونه ریسکهای سازمان را کاهش میدهد؟
کنترل زمانی مؤثر است که در محل مناسب جریان کار قرار بگیرد. گرفتن تأیید بعد از پرداخت، جای کنترل قبل از پرداخت را نمیگیرد. چارچوب کنترل داخلی COSO نیز کنترل را موضوعی فراتر از گزارشگری مالی میداند و بر اعتمادپذیری اطلاعات و پشتیبانی از اهداف سازمان تأکید دارد. موارد زیر، نمونههای پیشنهادی برای تبدیل این نگاه به طراحی اجرایی هستند؛ نه تضمین حذف همه خطاها.
۱. درخواست گمشده یا بدون مسئول
هر درخواست باید شناسه یکتا، وضعیت مشخص و مسئول فعلی داشته باشد. برای کارهای زماندار، مهلت، یادآوری و مسیر ارجاع تأخیر تعریف میشود. وجود جانشین نیز مانع وابستگی کامل کار به حضور یک نفر خواهد شد. صرف ارسال اعلان کافی نیست؛ باید معلوم باشد بعد از بیپاسخماندن آن چه اتفاقی میافتد.
۲. تأیید غیرمجاز و تعارض نقشها
میتوان نقش درخواستکننده، تأییدکننده و اجراکننده را تفکیک کرد و تأییدها را به مبلغ، نوع درخواست یا مرکز هزینه وابسته ساخت. مثلاً ثبتکننده درخواست نباید بتواند همان درخواست را با نقش دیگری بهتنهایی تأیید نهایی کند. این محدودیت باید سمت سرور و در تمام مسیرهای دسترسی، از جمله API، اعمال شود؛ پنهانکردن یک دکمه در فرم کنترل کافی نیست.
۳. اطلاعات ناقص، نامعتبر یا تغییرکرده پس از تأیید
اعتبارسنجی مبلغ، تاریخ، کد کالا و مدارک ضروری احتمال گردش درخواست ناقص را کم میکند. اگر پس از تأیید، مبلغ یا تأمینکننده تغییر کرد، بسته به سیاست سازمان باید تأیید دوباره لازم شود. لازم است نسخه اطلاعاتی که تأییدکننده دیده ثبت شود؛ ثبت یک علامت «تأیید شد» بدون مشخصبودن محتوای تأییدشده کافی نیست.
۴. خرید یا پرداخت تکراری
شناسه یکتای درخواست و کنترل ترکیبهایی مانند تأمینکننده و شماره فاکتور میتواند موارد مشکوک را شناسایی کند. در اتصال به سیستم مالی نیز ارسال مجدد یک پیام نباید پرداخت تازهای ایجاد کند. این کنترل به طراحی یکپارچهسازی، قواعد داده و رسیدگی به استثناها وابسته است؛ صرف خرید BPMS آن را خودکار فراهم نمیکند.
۵. نبود سابقه قابل پیگیری
باید بتوان مشخص کرد چه کسی، در چه زمانی، چه دادهای را تغییر داده و چرا درخواست را رد یا تأیید کرده است. برای قابل اتکابودن این سابقه، دسترسی به گزارش رویدادها، مدت نگهداری و امکان تغییر یا حذف آنها باید کنترل شود. حساب مشترک میان چند کارمند نیز ارزش انتساب اقدامات به اشخاص را از بین میبرد.
۶. وابستگی به افراد و مسیرهای غیررسمی
مستندسازی قواعد و مسیرهای جایگزین کمک میکند با جابهجایی یک کارمند، دانش اجرای کار از سازمان خارج نشود. با این حال، اگر کارکنان همچنان تأییدهای اصلی را بیرون سامانه بگیرند، دادههای BPMS تصویر کاملی نخواهند داد. سهولت استفاده، آموزش و حمایت مدیر فرآیند بهاندازه طراحی فنی مهماند.
مرز انتظار: فرآیندسازی احتمال برخی خطاها را کاهش میدهد و کشف آنها را آسانتر میکند؛ اما تبانی، اطلاعات نادرست، دسترسی مدیریتی نامناسب و اختلال زیرساخت همچنان ممکناند. پشتیبانگیری، بازیابی، بازبینی دسترسیها و رسیدگی به استثناها باید در کنار جریان کار طراحی شوند.
یک مثال عملی: طراحی فرآیند درخواست خرید
سناریوی زیر یک الگوی آموزشی است، نه گزارش نتیجه یک پروژه اجراشده:
- ثبت نیاز: متقاضی کالا، تعداد، دلیل خرید، مرکز هزینه و تاریخ نیاز را وارد میکند.
- بررسی موجودی: اگر کالا در انبار موجود باشد، درخواست به مسیر تحویل داخلی میرود؛ در غیر این صورت بررسی خرید ادامه پیدا میکند.
- بررسی بودجه: مسئول مجاز وضعیت بودجه را تأیید میکند؛ در صورت اتصال به سامانه مالی، باید نحوه رزرو بودجه و جلوگیری از مصرف همزمان آن هم مشخص شود.
- اخذ تأیید متناسب: مسیر تأیید با مبلغ، حساسیت کالا و ضوابط سازمان تعیین میشود، نه با یک زنجیره طولانی یکسان برای همه خریدها.
- خرید و دریافت: سفارش، اطلاعات تأمینکننده و نتیجه تحویل ثبت میشود. تحویل ناقص یا مغایرت باید مسیر روشن داشته باشد.
- کنترل پیش از پرداخت: تطبیق مدارک موردنیاز انجام میشود و مغایرتها پیش از ادامه کار تعیین تکلیف میشوند.
در کنار مسیر عادی باید انصراف، رد درخواست، اصلاح مبلغ، نبود مدیر، خطای اتصال و خرید فوری هم تعریف شوند. مسیر اضطراری نباید به راه دائمی دورزدن کنترلها تبدیل شود؛ دلیل استفاده، تأییدکننده و بازبینی بعدی آن باید ثبت شود.
برای گزارشگیری قابل اعتماد، چه دادههایی باید ثبت شوند؟
گزارش خوب از زمان طراحی فرم و مدل داده شروع میشود. مستندات مایکروسافت درباره دادههای فرآیندکاوی، شناسه پرونده، نام فعالیت و زمان رویدادها را از دادههای بنیادی تحلیل معرفی میکند. صرف نگهداری وضعیت فعلی درخواست، تاریخچه اجرای آن را بازسازی نمیکند.
برای مثال خرید، پیشنهاد میشود علاوه بر شناسه درخواست و فعالیت، زمان ایجاد، ارجاع، شروع رسیدگی، پایان مرحله، سررسید، واحد مسئول، نتیجه و دلیل برگشت ثبت شود. مبلغ، نوع خرید، تأمینکننده و نسخه فرآیند هم برای تحلیلهای تفکیکی مفیدند. تعریف هر فیلد باید ثابت و روشن باشد؛ «فوری» نباید برای هر واحد معنای متفاوتی داشته باشد.
زمان ارجاع تا پایان کار، لزوماً زمان کار واقعی کارمند نیست؛ ممکن است بیشتر آن انتظار برای پاسخ بیرونی باشد. اگر زمان رسیدگی فعال بهدرستی ثبت نمیشود، نباید از مدت حضور پرونده در کارتابل، هزینه نیروی انسانی یا بهرهوری فردی استخراج کرد.
ارزیابی عملکرد با BPMS: کدام شاخصها واقعاً مفیدند؟
شاخص باید تعریف، دامنه و کاربرد تصمیمگیری داشته باشد. تعریف APQC از زمان چرخه صدور سفارش خرید، زمان انتظار را نیز در کنار زمان انجام فعالیت در نظر میگیرد. بنابراین کوتاهبودن زمان انجام یک وظیفه به معنای سریعبودن کل فرآیند نیست.
زمان چرخه و پروندههای طولانی
زمان چرخه هر پرونده برابر فاصله نقطه شروع و پایان تعریفشده آن است. علاوه بر میانگین، میانه و صدک ۹۰ را بررسی کنید؛ صدک ۹۰ مدتزمانی است که حدود ۹۰ درصد پروندههای بررسیشده در آن یا زودتر تمام شدهاند. این شاخص کمک میکند تأخیرهای طولانی پشت یک میانگین مناسب پنهان نمانند.
رعایت مهلت یا SLA
یک تعریف پیشنهادی: تعداد درخواستهایی که تا سررسید انجام شدهاند، تقسیم بر کل درخواستهای دارای سررسید در دوره، ضربدر ۱۰۰. پروندههای هنوز باز اما سررسیدگذشته نیز در مخرج باقی میمانند. درباره روز کاری یا تقویمی، توقف مجاز زمان و درخواستهای لغوشده باید از ابتدا توافق شود.
نرخ دوبارهکاری
تعداد پروندههایی که حداقل یک بار برای اصلاح برگشتهاند، تقسیم بر تعداد پروندههای همان گروه بررسی، ضربدر ۱۰۰. تعداد دفعات برگشت را هم جداگانه گزارش کنید؛ یک پرونده با چهار برگشت با چهار پرونده تکبرگشتی یکسان نیست. تفکیک علت برگشت نشان میدهد مشکل از فرم، آموزش، مدارک یا ضابطه مبهم بوده است.
حجم کار باز و عمر صف
تعداد درخواستهای باز بهتنهایی کافی نیست. قدیمیترین پرونده، تعداد موارد سررسیدگذشته و توزیع زمان انتظار در هر مرحله نیز مهماند. واحدی که ده درخواست پیچیده دارد الزاماً عملکرد ضعیفتری از واحدی با پنجاه درخواست ساده ندارد.
کیفیت خروجی و هزینه
سرعت را همراه با کیفیت بسنجید: درصد تکمیل بدون اصلاح، مغایرت تحویل یا نیاز به بازگشایی پرونده میتواند مکمل باشد. محاسبه هزینه هر پرونده نیز به داده معتبر زمان کار فعال، نرخ هزینه و هزینههای جانبی نیاز دارد؛ از تعداد کلیک یا تعداد تأیید نمیتوان هزینه واقعی ساخت.
چگونه از داده BPMS برای ارزیابی منصفانه کارکنان استفاده کنیم؟
رتبهبندی کارکنان فقط براساس تعداد کار بستهشده ممکن است افراد را به انتخاب پروندههای ساده یا بستن زودهنگام کار تشویق کند. در تحلیل باید پیچیدگی پرونده، حجم ورودی، وابستگی به واحد دیگر، مرخصی و کیفیت خروجی لحاظ شود. بهتر است ابتدا مشکل فرآیند و توزیع کار بررسی شود و سپس عملکرد فرد در همان زمینه ارزیابی شود.
برای نمونه، اگر بیشتر تأخیر یک کارشناس مربوط به انتظار استعلام تأمینکننده است، افزایش فشار بر او لزوماً مسئله را حل نمیکند. شاید نیاز به تأمینکننده جایگزین، بازطراحی استعلام یا تغییر زمانبندی خرید باشد. دسترسی به گزارشهای فردی نیز باید محدود و هدف استفاده از آنها برای کارکنان روشن باشد.
گزارشهای BPMS چگونه به استراتژی سازمان کمک میکنند؟
گزارش زمانی راهبردی میشود که به انتخاب و اقدام منجر شود. نمونههای زیر پیشنهاد تحلیلیاند و اجرای آنها به کیفیت و دامنه داده سازمان بستگی دارد:
- ظرفیت و منابع: رشد حجم ورودی در کنار افزایش عمر صف مشخص میکند کدام مرحله به بازتوزیع کار، سادهسازی یا افزایش ظرفیت نیاز دارد.
- سیاست اختیارات: اگر خریدهای کممبلغ مدت زیادی در تأیید مدیریتی میمانند، میتوان تفویض اختیار محدود را با کنترلهای جایگزین بررسی کرد.
- اولویت سرمایهگذاری: ترکیب فراوانی کار، زمان رسیدگی و نرخ خطا کمک میکند مشخص شود خودکارسازی کدام فعالیت ارزش بیشتری دارد.
- مدیریت تأمینکنندگان: با اتصال اطلاعات سفارش و تحویل، میتوان تأخیر و مغایرت را به تفکیک تأمینکننده تحلیل کرد؛ داده گردش تأیید داخلی بهتنهایی برای قضاوت درباره تحویل کافی نیست.
- ریسک و کنترل: افزایش استفاده از مسیر اضطراری یا استثناها میتواند نشانه نامناسببودن ضابطه، ضعف برنامهریزی یا دورزدن کنترل باشد و نیاز به بررسی دارد.
- پیگیری اهداف سازمان: برای هدفی مانند کاهش زمان پاسخ به مشتری، باید زمان کل پاسخ، کیفیت پاسخ و حجم تقاضا کنار هم دیده شوند؛ بهبود یک مرحله نباید باعث انتقال صف به مرحله بعد شود.
برای هر گزارش چهار چیز مشخص کنید: سؤال مدیریتی، شاخص، مسئول تصمیم و زمان بازبینی. داشبوردی که فقط دیده میشود و هیچ تصمیمی به آن متصل نیست، بیشتر نمایش داده است تا ابزار مدیریت.
مثال عددی: از گزارش تأخیر تا تصمیم اصلاحی
این اعداد صرفاً فرضیاند. در یک ماه، ۲۰۰ درخواست خرید سررسید داشتهاند: ۱۴۰ مورد بهموقع تمام شده، ۴۰ مورد با تأخیر پایان یافته و ۲۰ مورد هنوز باز و سررسیدگذشتهاند. با تعریف SLA این مقاله، نرخ رعایت مهلت ۷۰ درصد است: ۱۴۰ تقسیم بر ۲۰۰. حذف ۲۰ پرونده باز از گزارش، تصویری خوشبینانه ایجاد میکند.
اگر از ۱۸۰ پرونده تکمیلشده، ۴۵ پرونده حداقل یک بار برای اصلاح برگشته باشند، نرخ دوبارهکاری در همین گروه ۲۵ درصد است. حال اگر عمده برگشتها به نبود کد کالا مربوط باشد، اقدام اولیه میتواند اصلاح فهرست انتخاب کالا و اعتبارسنجی فرم باشد، نه افزودن تأییدکننده جدید.
بعد از اصلاح، دورههای قابل مقایسه را با توجه به حجم و نوع درخواستها بررسی کنید. کاهش تأخیر بهتنهایی اثبات نمیکند که تمام بهبود حاصل تغییر فرم بوده است؛ تعطیلات، ترکیب پروندهها و تغییر نیروی انسانی هم میتوانند مؤثر باشند.
نقش ProcessMaker، فرمهای DynaForm و شروط مسیریابی
در نسخههای ۳.x پراسسمیکر، DynaForm ابزار طراحی فرمهای فرآیندی است. در چنین پیادهسازیای، فرم باید اطلاعات لازم همان مرحله را بگیرد و قواعد مسیریابی تعیین کنند پرونده با توجه به دادهها به کدام فعالیت برود. امکانات و شیوه اجرا در نسخههای مختلف یکسان نیست و باید با مستندات نسخه نصبشده تطبیق داده شود.
در مثال خرید، مبلغ و مرکز هزینه میتوانند در انتخاب مسیر تأیید نقش داشته باشند؛ اما شروط باید حالت مقدار خالی، مبلغ نامعتبر، تغییر اطلاعات و نبود مسئول را هم پوشش دهند. کنترلهای حیاتی نباید فقط به جاوااسکریپت فرم متکی باشند. ثبت داده لازم برای گزارش نیز باید همزمان با طراحی جریان در نظر گرفته شود، نه بعد از انباشتهشدن پروندهها.
از کجا شروع کنیم؟ یک نقشه اجرایی کوتاه
- یک فرآیند پرتکرار با مسئله مشخص و صاحب فرآیند همراه انتخاب کنید؛ نه لزوماً پیچیدهترین فرآیند سازمان.
- کار واقعی را با مشاهده، مصاحبه و بررسی چند پرونده بشناسید؛ دستورالعمل رسمی ممکن است با اجرا متفاوت باشد.
- تأییدها و فعالیتهای بدون ارزش را بازبینی و مسیر مطلوب و استثناها را مدلسازی کنید.
- کنترلهای ضروری، مسئول هر کنترل و دادههای موردنیاز شاخصها را مشخص کنید.
- فرمها و جریان را بسازید و سناریوهای عادی، خطا، انصراف و تغییر اطلاعات را آزمایش کنید.
- با گروه محدودی اجرا کنید، بازخورد بگیرید و پس از تثبیت، دامنه را گسترش دهید.
- شاخصها را دورهای بررسی کنید و برای هر اصلاح، مسئول و موعد تعیین کنید.
پرسشهای متداول درباره فرآیندسازی و BPMS
آیا BPMS جایگزین ERP یا نرمافزار مالی است؟
الزاماً خیر. BPMS میتواند گردش کار میان افراد و سامانهها را هماهنگ کند، در حالی که ثبت مالی یا مدیریت موجودی در سامانه تخصصی انجام شود. مرجع هر داده و مسئول بهروزرسانی آن باید روشن باشد.
آیا BPMS تمام ریسکها را از بین میبرد؟
خیر. کنترلهای مناسب میتوانند احتمال خطا و زمان کشف آن را کاهش دهند، اما کیفیت داده، دسترسیها، رفتار کاربران و قابلیت اطمینان زیرساخت همچنان تعیینکنندهاند.
آیا برای شروع به فرآیندکاوی نیاز داریم؟
خیر. میتوان با مدلسازی و چند شاخص ساده شروع کرد. فرآیندکاوی زمانی مفیدتر است که تاریخچه رویدادهای کافی و قابل اعتماد برای کشف مسیرهای واقعی و مقایسه آنها وجود داشته باشد.
آیا تعداد بیشتر تأییدها یعنی کنترل بهتر؟
خیر. هر تأیید باید ریسک مشخصی را پوشش دهد و تأییدکننده اطلاعات و اختیار لازم را داشته باشد. تأییدهای تکراری ممکن است فقط زمان انتظار را افزایش دهند.
آنچه در اجرای واقعی فرآیندهای سازمانی آموختهام
در تجربه طراحی و پیادهسازی فرآیندهای سازمانی، برای من روشن شده است که موفقیت یک پروژه BPMS فقط به کیفیت نمودار BPMN یا امکانات فنی سامانه وابسته نیست. پذیرش کاربران، سادگی مسیر اجرا، کیفیت دادهها و امکان اصلاح تدریجی فرآیند، تأثیر مستقیمی بر نتیجه دارند. بعضی نکاتی که در ادامه میآیند، حاصل مواجهه عملی من با کاربران، فرمها، شروط مسیریابی و نیازهای متغیر سازمانها هستند.
مقاومت اولیه کاربران همیشه به معنای مخالفت با فناوری نیست
در سازمانهایی که پیش از این فرآیندسازی یا BPMS نداشتهاند، معمولاً در ابتدای کار با نوعی مقاومت روبهرو میشویم. بخشی از این واکنش طبیعی است؛ زیرا افراد باید عادتهای قدیمی خود را کنار بگذارند، اطلاعات را با ساختار مشخصتری ثبت کنند و مراحل کارشان برای دیگران قابل مشاهده و پیگیری میشود.
طبق تجربه من، این مقاومت زمانی کمتر میشود که کاربران دلیل هر مرحله و فیلد را بدانند و احساس کنند سامانه بخشی از مشکلات روزانه آنها را حل میکند. وقتی درخواستها گم نمیشوند، وضعیت هر پرونده قابل مشاهده است و نیاز به تماس و پیگیری مداوم کاهش پیدا میکند، کاربران بهتدریج مزیت فرآیند جدید را لمس میکنند. در بسیاری از موارد، همان افرادی که در شروع نسبت به تغییر تردید داشتند، پس از مدتی خودشان پیشنهادهایی برای بهبود فرمها و مسیرها ارائه میدهند.
به همین دلیل، مشارکت کاربران در مرحله شناخت وضعیت موجود و اجرای آزمایشی اهمیت زیادی دارد. مشاهده کار واقعی، گفتوگو با افرادی که هر روز فرآیند را اجرا میکنند و توضیح منطق تغییرات، معمولاً نتیجه بهتری از ابلاغ یک فرآیند آماده و از بالا به پایین ایجاد میکند.
فرآیند بهتر است با یک نسخه ساده و قابل استفاده آغاز شود
یکی دیگر از آموختههای من این است که نباید از نسخه اول یک فرآیند انتظار داشت تمام حالتها و استثناهای احتمالی سازمان را پوشش دهد. طراحی بیش از حد پیچیده در شروع پروژه، فرمها را سنگین میکند، آزمون را دشوارتر میسازد و پذیرش کاربران را کاهش میدهد.
رویکردی که در عمل برای من نتیجه بهتری داشته، شروع با یک نسخه ساده، روشن و قابل کنترل است؛ نسخهای که مسیر اصلی، مسئولیتها، کنترلهای ضروری و مهمترین استثناها را پوشش دهد. پس از اجرا، دادههای واقعی و بازخورد کاربران نشان میدهند که کدام مرحله باعث تأخیر میشود، چه اطلاعاتی در فرم کم است و کدام شرط مسیریابی به اصلاح نیاز دارد.
این رویکرد با چرخه بهبود مستمر در مدیریت فرآیندهای کسبوکار هماهنگ است: فرآیند طراحی میشود، در مقیاس کنترلشده اجرا میشود، نتایج آن اندازهگیری میشود و سپس براساس شواهد بهبود پیدا میکند. البته سادهسازی اولیه نباید به حذف کنترلهای ضروری، الزامات قانونی یا ملاحظات امنیتی منجر شود.
دادههای مرجع فرمها باید بهصورت متمرکز مدیریت شوند
در طراحی فرمهای فرآیندی، استفاده مکرر از گزینههای ثابت داخل Dropdown یا Suggestion میتواند در آینده مشکلساز شود. فرض کنید فهرست واحدهای سازمان، مراکز هزینه، انواع درخواست یا نام تأمینکنندگان در چندین فرم بهصورت جداگانه وارد شده باشد. با هر تغییر، لازم است تمام فرمهای مرتبط پیدا و ویرایش شوند و احتمال باقیماندن اطلاعات قدیمی افزایش پیدا میکند.
در چنین شرایطی، ترجیح میدهم اطلاعات مرجع از یک منبع متمرکز مانند جدولهای کنترلشده در پایگاه داده SQL یا یک سرویس داده معتبر فراخوانی شوند. در این صورت، تغییر یک واحد سازمانی یا اضافهشدن یک گزینه جدید از همان منبع انجام میشود و تمام فرمهای وابسته اطلاعات بهروز را دریافت میکنند. این روش نگهداری فرآیندها را سادهتر میکند و ناسازگاری دادهها میان فرمهای مختلف را کاهش میدهد.
برای اجرای درست این الگو باید چند نکته رعایت شود: کاربران نباید مستقیماً به پایگاه داده دسترسی داشته باشند، پرسوجوها باید امن و پارامتری باشند، گزینههای غیرفعال بهجای حذف کامل نگهداری شوند و مقدار ثبتشده هر پرونده در آینده نیز قابل فهم باقی بماند. همچنین برای دادههای پرتکرار میتوان از کش کنترلشده استفاده کرد تا وابستگی فرم به پایگاه داده باعث کندی سامانه نشود.
فرم خوب باید به اندازه همان مرحله اطلاعات بخواهد
در پروژههای فرآیندی دیدهام که گاهی برای کاملبودن فرم، تعداد زیادی فیلد در همان مرحله اول از کاربر خواسته میشود؛ در حالی که بخشی از آن اطلاعات هنوز در دسترس نیست یا در مرحله دیگری باید تکمیل شود. این کار زمان ثبت درخواست را افزایش میدهد و احتمال درج اطلاعات حدسی یا نادرست را بیشتر میکند.
بهتر است هر نقش فقط اطلاعاتی را مشاهده و تکمیل کند که برای تصمیم یا فعالیت همان مرحله نیاز دارد. نمایش شرطی فیلدها، مقداردهی اولیه از دادههای معتبر و اعتبارسنجی متناسب با نوع درخواست، فرم را سادهتر میکند؛ اما کنترلهای اصلی باید در سمت سرور نیز اجرا شوند و فقط به ظاهر یا JavaScript فرم وابسته نباشند.
شاخصهای گزارشگیری باید پیش از اجرای فرآیند مشخص شوند
اگر نیازهای گزارشگیری بعد از اجرای فرآیند مطرح شوند، ممکن است داده لازم از ابتدا ثبت نشده باشد. به همین دلیل، هنگام طراحی فرآیند درباره گزارشهای موردنیاز مدیران نیز سؤال میکنم: قرار است زمان کدام مرحله اندازهگیری شود؟ دلیل برگشت درخواست چگونه ثبت میشود؟ تأخیر مربوط به چه واحدی است؟ چه چیزی یک پرونده را موفق، ناموفق یا نیازمند اصلاح میکند؟
پاسخ این پرسشها مشخص میکند چه فیلدها و رویدادهایی باید در BPMS ذخیره شوند. تجربه به من نشان داده است که یک داشبورد ساده با چند شاخص دقیق و قابل اقدام، معمولاً ارزش بیشتری از گزارشی شلوغ با نمودارهای متعدد و تعریفهای مبهم دارد.
برای من، طراحی فرآیند زمانی موفق است که کاربر بتواند وظیفه خود را با ابهام و پیگیری کمتری انجام دهد، مدیر بتواند وضعیت واقعی کار را ببیند و سازمان بتواند براساس دادههای ثبتشده، فرآیند را در دورههای بعد بهتر کند.
جمعبندی: فرآیند خوب هم کار را جلو میبرد، هم قابل سنجش است
اهمیت فرآیندسازی در سازمان در وصلکردن سه موضوع است: اجرای سادهتر کار، کنترل متناسب ریسک و تولید داده قابل اتکا. BPMS بستر اجرای این ارتباط است، نه جایگزین تحلیل و مدیریت. اگر پس از پیادهسازی بتوان فهمید کار کجا متوقف میشود، چرا برمیگردد و کدام اصلاح بیشترین ارزش را دارد، سامانه از یک کارتابل الکترونیکی به ابزار بهبود سازمان تبدیل شده است.
اگر قصد دارید یک فرآیند سازمانی را بازطراحی یا در ProcessMaker پیادهسازی کنید، میتوانید در صفحه درباره علی یزدیان با حوزه فعالیت من آشنا شوید.