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