دلایل شکست BPM مدیریت فرایند در سازمان ها
چرا بسیاری از پروژههای BPM شکست میخورند و چگونه میتوان از این اشتباهات جلوگیری کرد؟
راهنمای عملی برای مدیران، کارشناسان و مجریان پروژههای مدیریت فرایند کسبوکار
بسیاری از سازمانها با هدف افزایش بهرهوری، کاهش هزینهها، بهبود تجربه مشتری و افزایش چابکی، پروژههای مدیریت فرایند کسبوکار (BPM) را آغاز میکنند. با این حال، همه این پروژهها به موفقیت نمیرسند.
بررسی تجربه پروژههای مختلف نشان میدهد که شکست BPM معمولاً به دلیل ضعف فناوری نیست؛ بلکه بیشتر به دلیل اشتباهاتی مانند نبود حمایت مدیریت ارشد، اهداف نامشخص، انتخاب نادرست ابزار، اتوماسیون فرایندهای نامناسب، نبود مالک فرایند و بیتوجهی به مدیریت تغییر اتفاق میافتد.
در این مقاله، مهمترین اشتباهات پروژههای BPM را بررسی میکنیم و برای هر کدام، نشانهها، پیامدها و راهکارهای عملی ارائه میدهیم.
اگر فقط چند دقیقه وقت دارید، این نکات را به خاطر بسپارید
- BPM قبل از اینکه یک پروژه فناوری باشد، یک تغییر مدیریتی است.
- قبل از اتوماسیون، باید فرایند را تحلیل و بهبود داد.
- نرمافزار خوب نمیتواند یک فرایند بد را اصلاح کند.
- هر فرایند مهم باید یک مالک مشخص داشته باشد.
- موفقیت BPM بدون حمایت مدیریت ارشد امکانپذیر نیست.
- فرایندها باید دائماً پایش و بهبود داده شوند؛ BPM یک پروژه یکباره نیست.
چرا برخی شرکت ها در BPM شکست میخورند ؟
در نظر بگیرید که سه ماه از آغاز پروژه گذشته، جلسات متعددی برگزار شده، فرایندهای سازمان روی کاغذ ترسیم شده و نرمافزار مدیریت فرایند نیز خریداری شده است. اعضای تیم پروژه احساس میکنند همه چیز طبق برنامه پیش میرود.
در یکی از جلسات، مدیرعامل سؤال سادهای میپرسد:
« اگر امروز پروژه را متوقف کنیم، دقیقاً چه چیزی در سازمان بهتر شده است؟ »
چند لحظه سکوت …، مدیر فناوری اطلاعات از نصب نرمافزار صحبت میکند. مدیر منابع انسانی به برگزاری دورههای آموزشی اشاره میکند. مدیر مالی از هزینههای انجام شده میگوید و مسئول پروژه نیز تعدادی نمودار و گزارش ارائه می دهد. اما هیچکس نمیتواند با اطمینان توضیح دهد که کدام فرایند سریعتر، ارزانتر یا باکیفیتتر از گذشته اجرا میشود. زمان انجام کار چقدر کاهش یافته؟ هزینهها چقدر کمتر شده؟ رضایت مشتری چقدر افزایش پیدا کرده؟ کدام مشکل سازمان حل شده است؟
چند ماه بعد، کاربران دوباره به فایلهای Excel، فرمهای کاغذی و تماسهای تلفنی بازمیگردند و پروژهای که قرار بود تحول ایجاد کند، به یکی دیگر از پروژههای نیمهتمام سازمان تبدیل میشود.
اگر این داستان برای شما آشنا به نظر میرسد، تنها نیستید. بسیاری از سازمانها با وجود صرف زمان، بودجه و انرژی فراوان، به نتایجی که از مدیریت فرایندهای کسبوکار (BPM) انتظار دارند دست پیدا نمیکنند. جالب اینجاست که در بیشتر موارد، دلیل شکست پروژه نه نرمافزار است و نه فناوری. ریشه اصلی مشکلات معمولاً به تصمیمهایی برمیگردد که از همان روزهای نخست پروژه گرفته شدهاند.
مدیریت فرایندهای کسبوکار تنها به معنی ترسیم چند نمودار یا خرید یک سامانه اتوماسیون نیست. مدیریت فرایند کسبوکار یعنی سازمان بتواند بداند چگونه کار میکند، مشکلات خود را اندازهگیری کند، مسئولیتها را شفاف سازد و بهصورت مستمر عملکرد خود را بهبود دهد.
روشی برای مدیریت، بهبود و هدایت نحوه انجام کارها در سازمان است. هدف آن این است که فعالیتها به جای وابستگی به افراد، بر اساس فرایندهای شفاف، قابل اندازهگیری و قابل بهبود انجام شوند. به همین دلیل، موفقیت یک پروژه BPM بیش از آنکه به فناوری وابسته باشد، به میزان آمادگی سازمان، همراهی مدیران، مشارکت کارکنان و شیوه اجرای پروژه بستگی دارد.
در سالهای اخیر، تجربه اجرای پروژههای متعدد در سازمانهای مختلف نشان داده است که بخش قابل توجهی از شکستها، الگوهای مشترکی دارند. سازمانها معمولاً اشتباهات مشابهی را تکرار میکنند؛ اشتباهاتی که اگر از ابتدا شناخته شوند، میتوان با هزینهای بسیار کمتر از بروز آنها جلوگیری کرد.
در این مقاله، هفت مورد از رایجترین اشتباهات پروژههای BPM را بررسی میکنیم. علاوه بر آن، دو اشتباه مهم دیگر که در بسیاری از پروژههای ایرانی مشاهده میشود نیز معرفی خواهد شد. برای هر مورد، علاوه بر بیان علت، نشانهها و پیامدهای آن، راهکارهای عملی و قابل اجرا ارائه میشود تا مدیران، کارشناسان و مجریان پروژه بتوانند از همان ابتدای مسیر، احتمال موفقیت پروژه خود را افزایش دهند.
مهمترین اشتباهات پروژههای BPM
قبل از ورود به جزئیات، تصویر کلی این اشتباهات را مرور کنیم.
| اشتباه | نشانه رایج | پیامد اصلی | راهکار کلیدی |
| نبود حمایت مدیریت ارشد | تصمیمهای متناقض و توقف پروژه | کاهش انگیزه و شکست پروژه | تعیین حامی اجرایی (Executive Sponsor) |
| اهداف نامشخص | اختلاف بین واحدها درباره هدف پروژه | دوبارهکاری و اتلاف منابع | تعریف اهداف و شاخصهای قابل اندازهگیری |
| محیط آزمایشی ضعیف | اجرای مستقیم تغییرات در محیط عملیاتی | خطا و اختلال در خدمات | ایجاد محیط تست و اجرای پایلوت |
| انتخاب ابزار نامناسب | تمرکز بر نرمافزار به جای نیاز سازمان | هزینه بالا و کارایی پایین | انتخاب ابزار بر اساس نیاز فرایند |
| وجود فرایندهای پنهان | وابستگی شدید به افراد | توقف کار با جابهجایی کارکنان | مستندسازی و شفافسازی فرایندها |
| نبود قابلیت رهگیری | نامشخص بودن وضعیت پروندهها | تأخیر و نارضایتی مشتری | طراحی داشبورد و شاخصهای پایش |
| قراردادهای نامناسب | مقاومت پیمانکار در برابر تغییر | کاهش انعطاف پروژه | همراستا کردن قراردادها با اهداف فرایندی |
| اتوماسیون قبل از بهبود | دیجیتالی شدن فرایندهای ناکارآمد | افزایش سرعت انجام اشتباهات | ابتدا بهبود، سپس اتوماسیون |
| نبود مالک فرایند | مشخص نبودن مسئول پاسخگو | فراموش شدن فرایند پس از پروژه | تعیین Process Owner برای هر فرایند |
این جدول تنها خلاصهای از موضوعات مقاله است. در ادامه، هر یک از این اشتباهات را با مثالهای واقعی و راهکارهای عملی بررسی خواهیم کرد.
1 . نبود حمایت واقعی مدیریت ارشد؛
پروژهای که حامی ندارد، دوام هم ندارد
بسیاری از مدیران تصور میکنند حمایت از پروژه BPM یعنی امضای ابلاغیه آغاز پروژه یا حضور در جلسه افتتاحیه. اما تجربه نشان داده است که این نوع حمایت، معمولاً چند هفته بیشتر دوام نمیآورد.
پروژه مدیریت فرایندهای کسبوکار، برخلاف بسیاری از پروژههای فناوری اطلاعات، مستقیماً با نحوه انجام کار افراد سروکار دارد. وقتی قرار است وظایف تغییر کند، مسئولیتها بازتعریف شود، برخی فعالیتهای تکراری حذف شوند یا شاخصهای عملکرد تغییر کنند، مقاومت کارکنان و حتی مدیران میانی کاملاً طبیعی است. در چنین شرایطی، اگر مدیران ارشد به صورت مستمر از پروژه حمایت نکنند، پروژه بتدریج انرژی خود را از دست میدهد.
حمایت واقعی مدیریت ارشد به این معناست که مدیران سازمان در تصمیمهای مهم پروژه حضور داشته باشند، اختلاف میان واحدها را حل کنند، منابع موردنیاز را تأمین کنند و در عمل نشان دهند که بهبود فرایندها یکی از اولویتهای سازمان است.
در بسیاری از پروژههای ناموفق، حمایت مدیرعامل تنها در ابتدای پروژه دیده میشود. پس از مدتی، جلسات راهبری برگزار نمیشود، تصمیمها به تعویق میافتد و واحدهای مختلف هر کدام مسیر خود را دنبال میکنند. نتیجه این وضعیت، پروژهای است که بدون تصمیمگیرنده و بدون پشتوانه ادامه پیدا میکند.
نشانههای این مشکل
اگر در پروژه خود با موارد زیر روبهرو هستید، احتمالاً حمایت مدیریت ارشد کافی نیست:
- جلسات کمیته راهبری بهطور مرتب برگزار نمیشود.
- مدیران واحدها پروژه را جزو اولویتهای خود نمیدانند.
- تصمیمهای مهم هفتهها بدون نتیجه باقی میماند.
- بودجه یا نیروی انسانی پروژه بهراحتی کاهش پیدا میکند.
- هر واحد سازمانی قوانین خاص خود را اجرا میکند.
پیامدهای این اشتباه
نبود حمایت مدیریت ارشد معمولاً به مشکلات زیر منجر میشود:
- افزایش مقاومت کارکنان در برابر تغییر
- اختلاف میان واحدهای سازمانی
- طولانی شدن زمان اجرای پروژه
- کاهش انگیزه تیم پروژه
- توقف یا نیمهتمام ماندن پروژه
راهکارهای عملی
برای جلوگیری از این مشکل، چند اقدام ساده اما مؤثر وجود دارد:
- برای پروژه، یک حامی اجرایی (Executive Sponsor) مشخص کنید؛ فردی که اختیار تصمیمگیری داشته باشد و بتواند موانع بین واحدها را برطرف کند.
- جلسات کمیته راهبری را بهصورت منظم و با خروجی مشخص برگزار کنید.
- گزارش پیشرفت پروژه را به زبان مدیران ارائه دهید؛ یعنی به جای نمایش تعداد نمودارهای ( BPMN چیست )، درباره کاهش زمان انجام کار، کاهش هزینه یا افزایش رضایت مشتری صحبت کنید.
- موفقیتهای کوچک پروژه را به مدیران ارشد اطلاع دهید تا حمایت آنها تقویت شود.
یک مثال واقعی
در یکی از پروژههای بهبود فرایند، تیم پروژه پس از چند ماه مدلسازی، آماده اجرای تغییرات بود. اما یکی از واحدهای سازمانی با حذف یک مرحله از فرایند مخالفت کرد. این اختلاف نزدیک به دو ماه پروژه را متوقف کرد، زیرا هیچکس اختیار تصمیمگیری نهایی را نداشت.
پس از ورود مدیرعامل و تشکیل کمیته راهبری، موضوع در همان جلسه اول تعیین تکلیف شد و پروژه دوباره به جریان افتاد.
درس مهم: در پروژههای BPM، نبود تصمیمگیرنده قدرتمند، معمولاً از هر مشکل فنی خطرناکتر است.
۲. اهداف نامشخص؛ وقتی هیچکس نمیداند پروژه دقیقاً قرار است چه چیزی را بهبود دهد
یکی از رایجترین اشتباهات در پروژههای BPM این است که همه درباره «بهبود فرایند» صحبت میکنند، اما هر فرد برداشت متفاوتی از این عبارت دارد.
مدیر مالی انتظار کاهش هزینهها را دارد. مدیر فناوری اطلاعات به دنبال یکپارچهسازی سامانههاست. مدیر منابع انسانی به فکر استانداردسازی وظایف است و مدیرعامل افزایش رضایت مشتری را هدف اصلی میداند.
در ظاهر، همه از پروژه حمایت میکنند؛ اما در عمل، هر واحد در جهتی متفاوت حرکت میکند. نتیجه این اختلاف، پروژهای است که پس از ماهها فعالیت، هیچیک از ذینفعان از نتیجه آن رضایت کامل ندارند.
پیش از شروع هر پروژه BPM باید پاسخ روشنی برای این پرسش وجود داشته باشد:
« اگر پروژه موفق شود، چه تغییری باید در سازمان مشاهده کنیم؟ »
اگر پاسخ این سؤال مبهم باشد، احتمالاً کل پروژه نیز مبهم خواهد بود.
اهداف پروژه باید مشخص، قابلاندازهگیری و قابل ارزیابی باشند. عباراتی مانند «بهبود عملکرد سازمان» یا «افزایش بهرهوری» اگر به شاخصهای مشخص تبدیل نشوند، در عمل کمکی به مدیریت پروژه نمیکنند.
برای مثال، به جای هدف کلی «افزایش بهرهوری»، میتوان هدف را اینگونه تعریف کرد:
- کاهش زمان رسیدگی به درخواست خرید از ۱۰ روز به ۴ روز
- کاهش خطاهای ثبت اطلاعات به کمتر از دو درصد
- حذف کامل گردش کاغذ در فرایند مرخصی کارکنان
افزایش رضایت مشتری از ۷۰ به ۸۵ درصد
وقتی هدف به یک عدد یا شاخص تبدیل میشود، همه اعضای تیم میدانند قرار است به چه نتیجهای برسند.
نشانههای این مشکل
- اعضای تیم درباره هدف پروژه توافق ندارند.
- شاخص مشخصی برای موفقیت پروژه تعریف نشده است.
- در جلسات، درباره اولویتها اختلاف نظر وجود دارد.
- پس از پایان هر فاز، مشخص نیست پروژه چقدر موفق بوده است.
پیامدها
- تغییر مداوم محدوده پروژه
- دوبارهکاری
- افزایش هزینه و زمان اجرا
- نارضایتی مدیران و کاربران
- دشوار شدن ارزیابی موفقیت پروژه
راهکارهای عملی
- در ابتدای پروژه، اهداف را به شاخصهای قابلاندازهگیری (KPI) تبدیل کنید.
- برای هر فرایند، وضعیت موجود و وضعیت مطلوب را مشخص کنید.
- درباره اولویتهای پروژه با همه ذینفعان به توافق برسید.
- موفقیت پروژه را بر اساس نتایج کسبوکار بسنجید، نه تعداد فرایندهای مدلسازیشده.
در یکی از سازمانها، هدف پروژه «دیجیتالی کردن فرایندها» اعلام شده بود. پس از چند ماه، تقریباً تمام فرمهای کاغذی به فرمهای الکترونیکی تبدیل شدند؛ اما زمان انجام کار هیچ تغییری نکرد، زیرا مراحل غیرضروری همچنان در فرایند باقی مانده بودند.
در واقع، سازمان فقط کاغذ را حذف کرده بود، نه اتلاف زمان را.
این تجربه یک نکته مهم را یادآوری میکند:
BPM با دیجیتالی کردن فرمها آغاز نمیشود؛ با تعریف درست مسئله آغاز میشود.
۳. نادیده گرفتن محیط آزمایش و اجرای پایلوت؛ آزمایش نکردن، پرهزینهترین اشتباه پروژه است
یکی از تفاوتهای مهم پروژههای موفق و ناموفق BPM، نحوه ورود آنها به مرحله اجراست. برخی سازمانها پس از پایان مدلسازی و پیادهسازی، تغییرات را مستقیماً در محیط عملیاتی اعمال میکنند؛ در حالی که برخی دیگر ابتدا فرایند را در یک محیط کنترلشده آزمایش میکنند، ایرادها را برطرف میکنند و سپس آن را در کل سازمان اجرا میکنند.
تفاوت این دو رویکرد، گاهی موفقیت یا شکست کل پروژه را رقم میزند.
هیچ فرایندی از همان ابتدا کامل نیست. حتی اگر بهترین تحلیلگران، دقیقترین مدلها و مناسبترین نرمافزار انتخاب شده باشد، باز هم در مرحله اجرا نکاتی آشکار میشود که در جلسات تحلیل قابل پیشبینی نبودهاند. کاربران واقعی، شرایط واقعی و حجم واقعی کار، معمولاً نقاط ضعفی را آشکار میکنند که روی کاغذ دیده نمیشوند.
به همین دلیل، اجرای آزمایشی (Pilot) یکی از اصول پذیرفتهشده در پروژههای BPM است. هدف از اجرای پایلوت، اثبات موفقیت نیست؛ بلکه کشف مشکلات پیش از گسترش آنها در کل سازمان است.
متأسفانه برخی مدیران، اجرای پایلوت را اتلاف زمان میدانند و برای رسیدن سریعتر به نتیجه، آن را حذف میکنند. این تصمیم شاید در ظاهر باعث کوتاه شدن زمان پروژه شود، اما در عمل هزینه اصلاح اشتباهات را چند برابر خواهد کرد.
نشانههای این مشکل
اگر پروژه شما با موارد زیر روبهرو است، احتمالاً مرحله آزمایش بهدرستی انجام نشده است:
- فرایند جدید مستقیماً در محیط عملیاتی اجرا شده است.
- کاربران اولین بار هنگام استفاده واقعی با سیستم آشنا میشوند.
- هر روز درخواستهای اصلاحی جدید ثبت میشود.
- خطاهای غیرمنتظره در اطلاعات یا گردش کار مشاهده میشود.
- اعتماد کاربران به سیستم بهسرعت کاهش پیدا میکند.
پیامدها
نداشتن محیط آزمایش مناسب میتواند پیامدهای زیر را به همراه داشته باشد:
- اختلال در ارائه خدمات به مشتریان
- افزایش حجم خطاها
- کاهش اعتماد کاربران
- افزایش هزینه اصلاحات
- طولانی شدن زمان استقرار
در برخی موارد، همین تجربه ناموفق باعث میشود کاربران برای همیشه نسبت به پروژههای بعدی BPM بدبین شوند.
راهکارهای عملی
برای کاهش این ریسک، اقدامات زیر توصیه میشود:
- پیش از اجرای نهایی، محیطی مشابه محیط واقعی برای آزمایش فرایند ایجاد کنید.
- ابتدا فرایند را در یک واحد یا شعبه محدود اجرا کنید و پس از رفع مشکلات، آن را به سایر بخشها گسترش دهید.
- علاوه بر آزمون فنی، از کاربران نهایی نیز بخواهید فرایند را اجرا کنند و بازخورد بدهند.
- سناریوهای غیرعادی مانند خطاهای سیستمی، مرخصی کارکنان، افزایش حجم درخواستها یا قطع ارتباط با سامانههای دیگر را نیز آزمایش کنید.
- معیارهای موفقیت پایلوت را از قبل مشخص کنید؛ برای مثال، زمان انجام کار، نرخ خطا یا رضایت کاربران.
یک مثال واقعی
فرض کنید سازمانی فرایند درخواست خرید را بازطراحی کرده و بدون اجرای پایلوت، آن را برای همه واحدها فعال میکند. دو روز بعد مشخص میشود در صورت مرخصی مدیر واحد، هیچ مکانیزمی برای جانشینی پیشبینی نشده است. در نتیجه صدها درخواست در صف تأیید باقی میماند و فعالیت سازمان دچار اختلال میشود.
اگر همین فرایند ابتدا در یک واحد کوچک آزمایش شده بود، این مشکل پیش از استقرار سراسری شناسایی و برطرف میشد.
قاعدهای ساده اما مهم: هرچه هزینه آزمایش بیشتر به نظر برسد، هزینه اصلاح اشتباه پس از استقرار، بسیار بیشتر خواهد بود.
۴. انتخاب ابزار به جای انتخاب راهکار؛
نرمافزار، جایگزین تحلیل فرایند نیست
یکی از رایجترین اشتباهات در پروژههای BPM، از همان روز نخست آغاز میشود؛ زمانی که سازمان قبل از شناخت دقیق مسئله، به دنبال خرید نرمافزار میرود.
بارها دیده شده است که اولین سؤال مدیران این نیست که «کدام فرایند را باید بهبود دهیم؟»، بلکه این است که «بهترین نرمافزار BPM کدام است؟»
این نگاه، معمولاً پروژه را از مسیر اصلی خود خارج میکند.
نرمافزار BPM تنها یک ابزار است؛ همانگونه که یک نرمافزار طراحی، معمار خوبی نمیسازد، خرید یک سامانه BPM نیز بهتنهایی باعث بهبود فرایندهای سازمان نمیشود.
انتخاب ابزار باید آخرین مرحله تصمیمگیری باشد، نه اولین آن.
پیش از انتخاب هر فناوری، باید مشخص شود:
- چه مسئلهای قرار است حل شود؟
- کدام فرایندها در اولویت هستند؟
- حجم کاربران چقدر است؟
- سامانه باید با چه سیستمهایی یکپارچه شود؟
- آیا هدف صرفاً مدلسازی است یا اجرای کامل فرایند؟
- سازمان در آینده چه برنامهای برای توسعه فرایندها دارد؟
پاسخ به این پرسشها تعیین میکند که چه نوع ابزاری مناسب سازمان است.
امروزه ابزارهای متنوعی در حوزه مدیریت فرایند وجود دارند؛ از نرمافزارهای مدلسازی و مستندسازی گرفته تا موتورهای اجرای فرایند، سامانههای اتوماسیون، ابزارهای استخراج فرایند (Process Mining)، راهکارهای RPA و پلتفرمهای Low-Code. هر کدام از این ابزارها برای هدف مشخصی طراحی شدهاند و جایگزین یکدیگر نیستند.
به همین دلیل، انتخاب نرمافزار صرفاً بر اساس تبلیغات، قیمت یا محبوبیت آن، یکی از پرهزینهترین اشتباهات پروژه است.
نشانههای این مشکل
- نرمافزار پیش از تحلیل نیازهای سازمان خریداری شده است.
- قابلیتهای زیادی خریداری شده که هرگز استفاده نمیشوند.
- کاربران برای انجام کارهای ساده مجبور به انجام مراحل پیچیده هستند.
- پس از مدتی، بخشی از فعالیتها دوباره خارج از سامانه انجام میشود.
پیامدها
- افزایش هزینههای خرید و نگهداری
- پیچیده شدن فرایندها
- کاهش پذیرش کاربران
- وابستگی بیش از حد به فناوری
- دشواری توسعه سیستم در آینده
راهکارهای عملی
برای انتخاب درست ابزار، این مسیر را دنبال کنید:
- ابتدا فرایندها و نیازهای واقعی سازمان را تحلیل کنید.
- اهداف کوتاهمدت و بلندمدت پروژه را مشخص کنید.
- معیارهای ارزیابی نرمافزار را قبل از بررسی محصولات تدوین کنید.
- امکان یکپارچگی با سامانههای موجود را بررسی کنید.
- علاوه بر امکانات فنی، عواملی مانند سهولت استفاده، قابلیت توسعه، پشتیبانی و هزینه نگهداری را نیز در نظر بگیرید.
- پیش از خرید نهایی، اجرای یک نمونه آزمایشی (Proof of Concept) را در دستور کار قرار دهید.
یک مثال واقعی
سازمانی با هدف کاهش زمان رسیدگی به درخواستهای منابع انسانی، یک سامانه قدرتمند BPM خریداری کرد. اما پس از چند ماه مشخص شد مشکل اصلی، نبود استاندارد در فرایندها و تعریف نشدن مسئولیتها بوده است، نه کمبود نرمافزار.
در نتیجه، سازمان نرمافزار جدیدی در اختیار داشت، اما همان فرایندهای قدیمی را با ظاهری مدرنتر اجرا میکرد.
این تجربه یک واقعیت مهم را یادآوری میکند:
ابزار مناسب، یک فرایند خوب را توانمندتر میکند؛ اما نمیتواند یک فرایند ضعیف را به فرایندی کارآمد تبدیل کند.
نکته کاربردی
ترتیب صحیح تصمیمگیری نقش مهمی در موفقیت پروژه های BPM دارد:
همین جابهجایی ساده، آغاز بسیاری از شکستهای پروژههای BPM است.
۵. فرایندهای پنهان : وقتی سازمان به جای سیستم، به افراد وابسته است
در بسیاری از سازمانها، بخشی از مهمترین فعالیتها نه در دستورالعملها ثبت شدهاند، نه در سامانهها وجود دارند و نه کسی دقیقاً میداند چگونه انجام میشوند. این فعالیتها معمولاً در طول سالها و بهصورت تدریجی شکل گرفتهاند؛ یک کارشناس برای حل یک مشکل، روش خاصی پیدا کرده، مدیر دیگری یک مرحله جدید اضافه کرده و واحد دیگری برای هماهنگی بیشتر، یک کنترل دستی ایجاد کرده است.
به مرور زمان، مجموعهای از روشهای غیررسمی شکل میگیرد که اگرچه ممکن است در کوتاهمدت کارها را پیش ببرد، اما سازمان را به افراد خاص وابسته میکند.
این همان چیزی است که میتوان آن را فرایند پنهان (Hidden Process) نامید.
در این شرایط، سازمان تصور میکند فرایند مشخصی دارد، اما در واقع بخش مهمی از دانش عملیاتی فقط در ذهن کارکنان باتجربه وجود دارد.
برای مثال، ممکن است در یک شرکت همه بدانند که درخواست خرید چگونه انجام میشود. اما وقتی دقیقتر بررسی میکنیم، متوجه میشویم:
- کارشناس تدارکات قبل از ثبت درخواست، با چند نفر تلفنی هماهنگ میکند.
- مدیر واحد برای بعضی درخواستها یک تأیید غیررسمی انجام میدهد.
- مسئول مالی یک کنترل خاص انجام میدهد که در هیچ دستورالعملی نوشته نشده است.
- یک فایل Excel شخصی برای پیگیری وضعیت درخواستها وجود دارد.
در ظاهر، فرایند وجود دارد؛ اما در واقع، بخش مهمی از آن خارج از سیستم و مستندات رسمی سازمان اجرا میشود.
چرا فرایندهای پنهان ایجاد میشوند؟
ایجاد فرایندهای پنهان معمولاً نتیجه بیتوجهی یا کوتاهی افراد نیست. بلکه اغلب حاصل رشد طبیعی سازمان است.
برخی دلایل رایج عبارتاند از:
- رشد سریع سازمان بدون بازطراحی فرایندها
- تغییر قوانین یا شرایط کسبوکار
- اضافه شدن کنترلهای جدید بدون اصلاح فرایند اصلی
- نبود مستندسازی مناسب
- تمرکز دانش در اختیار چند فرد باتجربه
- نبود مالک مشخص برای فرایند
در بسیاری از سازمانها، کارکنان باتجربه نقش یک «سیستم انسانی» را ایفا میکنند. آنها میدانند چه کاری را، چه زمانی و با چه کسی انجام دهند تا کار جلو برود.
مشکل زمانی آغاز میشود که این افراد:
- سازمان را ترک کنند،
- به واحد دیگری منتقل شوند،
- بازنشسته شوند،
- یا برای مدتی در دسترس نباشند.
در این حالت، سازمان ناگهان متوجه میشود که بسیاری از فعالیتهای حیاتی به دانش افراد وابسته بوده است.
نشانههای وجود فرایندهای پنهان
برخی نشانههای مهم عبارتاند از:
- کارکنان جدید مدت زیادی برای یادگیری کارها نیاز دارند.
- پاسخ بسیاری از سؤالات این است: «از فلانی بپرسید، او میداند.»
- دستورالعملهای رسمی با روش واقعی انجام کار تفاوت دارند.
- تعداد زیادی فایل Excel شخصی برای مدیریت کارها وجود دارد.
- فرآیندها با تماس تلفنی، پیامرسان یا ایمیلهای شخصی تکمیل میشوند.
- با جابهجایی یک فرد، سرعت انجام کار بهشدت کاهش پیدا میکند.
پیامدهای فرایندهای پنهان
وجود این نوع فرایندها مشکلات زیادی برای سازمان ایجاد میکند:
۱. کاهش قابلیت توسعه سازمان
وقتی انجام کار وابسته به افراد خاص باشد، رشد سازمان دشوار میشود؛ زیرا هر افزایش حجم کار نیازمند افزایش افراد متخصص است.
۲. افزایش ریسک عملیاتی
اگر فرد کلیدی سازمان را ترک کند، بخشی از دانش سازمان نیز از بین میرود.
۳. دشواری در اتوماسیون
اتوماسیون یک فرایند زمانی امکانپذیر است که فرایند شناخته شده باشد. نمیتوان چیزی را که وجود رسمی ندارد، به درستی خودکار کرد.
۴. کاهش قابلیت کنترل و اندازهگیری
وقتی مسیر واقعی انجام کار مشخص نیست، اندازهگیری زمان، هزینه و کیفیت نیز دشوار خواهد بود.
راهکارهای عملی برای شناسایی و حذف فرایندهای پنهان
۱. فرایند واقعی را از کاربران یاد بگیرید، نه فقط از دستورالعملها
یکی از اشتباهات رایج در پروژههای BPM این است که تیم تحلیل فقط مستندات رسمی سازمان را بررسی میکند.
اما در بسیاری از موارد، مستندات نشاندهنده چیزی است که باید اتفاق بیفتد، نه چیزی که واقعاً اتفاق میافتد.
برای شناخت فرایند واقعی باید:
- با کارکنانی که کار را انجام میدهند مصاحبه کرد.
- مسیر واقعی پروندهها را دنبال کرد.
- استثناها و راهحلهای دستی را شناسایی کرد.
- تفاوت بین «فرایند رسمی» و «فرایند واقعی» را مشخص کرد.
۲. دانش افراد کلیدی را استخراج و ثبت کنید
کارکنان باتجربه سرمایه سازمان هستند. هدف BPM حذف نقش آنها نیست؛ بلکه تبدیل دانش فردی آنها به دانش سازمانی است.
این کار میتواند از طرق زیر انجام شود:
- جلسات انتقال دانش
- مستندسازی تجربیات
- ثبت قوانین کسبوکار
- ایجاد راهنماهای اجرایی
۳. فرایندها را بهصورت دورهای بازبینی کنید
فرایندها موجودات ثابت نیستند. یک فرایند که پنج سال قبل مناسب بوده، ممکن است امروز باعث کندی سازمان شود.
بهبود مستمر باید بخشی از مدیریت فرایند باشد.
یک مثال واقعی
در یک سازمان، فرایند صدور مجوز بهصورت رسمی ۱۲ مرحله داشت. طبق دستورالعمل، زمان انجام کار باید پنج روز بود.
اما بررسی واقعی نشان داد که کارشناسان برای جلوگیری از برگشت پروندهها، قبل از ثبت رسمی درخواست، آن را برای چند نفر ارسال میکنند تا نظر غیررسمی بدهند.
این هماهنگیها باعث شده بود زمان واقعی انجام کار به سه هفته برسد.
در طراحی مجدد فرایند، این فعالیتهای پنهان شناسایی شدند و بخشی از آنها به کنترلهای رسمی تبدیل شد و بخش غیرضروری حذف شد.
نتیجه:
- زمان انجام فرایند کاهش یافت.
- وابستگی به افراد کمتر شد.
امکان اتوماسیون واقعی فراهم شد.
نکته کلیدی: سازمانی که فرایندهای پنهان خود را نمیشناسد، در واقع نمیداند چگونه کار میکند.
۶. نبود دید و قابلیت ردیابی فرایند؛ وقتی سازمان نمیداند کارها کجا هستند
یکی از مهمترین اهداف BPM این است که سازمان بتواند به یک سؤال ساده پاسخ دهد:
«الان وضعیت این کار یا درخواست در کجای فرایند قرار دارد؟»
اما در بسیاری از سازمانها، پاسخ به این سؤال ساده نیست.
یک درخواست ممکن است بین چند واحد، چند سامانه و چند نفر گردش کند، بدون اینکه تصویر روشنی از وضعیت آن وجود داشته باشد.
کاربر نمیداند درخواستش کجاست.
مدیر نمیداند کدام مرحله باعث تأخیر شده است.
واحد پشتیبان نمیتواند علت مشکل را پیدا کند.
این مشکل معمولاً زمانی شدیدتر میشود که یک فرایند بین چند واحد سازمانی یا حتی چند سازمان مختلف توزیع شده باشد.
برای مثال، فرایند خرید ممکن است شامل:
- واحد درخواستکننده
- مدیریت
- تدارکات
- مالی
- انبار
- تأمینکننده خارجی
باشد.
هر واحد ممکن است ابزار، روش و اولویتهای خود را داشته باشد. در چنین شرایطی، بدون طراحی مناسب فرایند و مکانیزم رهگیری، کنترل کل مسیر بسیار دشوار میشود.
یکی از ارزشهای اصلی مدیریت فرایند کسبوکار این است که سازمان بتواند فعالیتهای خود را مشاهده، اندازهگیری و کنترل کند. بدون دید کافی، حتی بهترین فرایندها نیز پس از مدتی دچار انحراف میشوند.
فرض کنید مشتری یک درخواست خدمات ثبت کرده است. چند روز بعد با سازمان تماس میگیرد و میپرسد:
« درخواست من الان در چه مرحلهای است؟»
اگر پاسخ سازمان این باشد که:
- «باید از واحد مربوطه سؤال کنیم.»
- «احتمالاً پیش مدیر است.»
- «فکر کنم منتظر تأیید مالی باشد.»
این یعنی سازمان کنترل مناسبی بر فرایند خود ندارد.
در یک سازمان فرایندمحور، وضعیت هر درخواست باید قابل مشاهده باشد؛ مشخص باشد چه کسی مسئول مرحله فعلی است، چه مدت در آن مرحله مانده و گلوگاه اصلی کجاست.
چرا قابلیت ردیابی فرایند اهمیت دارد؟
قابلیت ردیابی (Traceability) تنها برای کنترل مدیران نیست. این قابلیت برای همه ذینفعان ارزش ایجاد میکند:
برای مدیران
- شناسایی نقاط تأخیر
- تصمیمگیری بر اساس داده واقعی
- ارزیابی عملکرد واحدها
برای کارکنان
- مشخص بودن مسئولیتها
- کاهش پیگیریهای غیرضروری
- جلوگیری از دوبارهکاری
برای مشتریان
- اطلاع از وضعیت درخواست
- کاهش زمان پاسخگویی
- افزایش اعتماد به سازمان
نشانههای نبود قابلیت ردیابی
برخی علائم رایج عبارتاند از:
- برای پیدا کردن وضعیت یک درخواست باید چند تماس تلفنی انجام شود.
- گزارشها بر اساس حدس و تجربه افراد تهیه میشوند.
- مشخص نیست تأخیر در کدام مرحله اتفاق افتاده است.
- مدیران فقط زمانی از مشکل مطلع میشوند که مشتری یا کارکنان شکایت کنند.
- اطلاعات فرایند در چندین سامانه جداگانه پراکنده است.
پیامدهای نبود دید کافی
۱. افزایش زمان انجام فرایند
وقتی مشخص نیست کار در کجا متوقف شده، پیگیری و رفع مشکل زمان زیادی میگیرد.
۲. کاهش مسئولیتپذیری
وقتی مالک هر مرحله مشخص نیست، افراد احساس مسئولیت کمتری نسبت به نتیجه نهایی دارند.
۳. تصمیمگیری بدون داده
مدیران مجبور میشوند بر اساس تجربه شخصی تصمیم بگیرند، نه اطلاعات واقعی.
۴. دشواری بهبود مستمر
برای بهبود یک فرایند، ابتدا باید بدانیم مشکل دقیقاً کجاست. بدون داده، بهبود بیشتر شبیه حدس زدن است.
راهکارهای عملی جلوگبری از دلایل شکست مدیریت فرایند
برای ایجاد دید و قابلیت ردیابی مناسب، اقدامات زیر پیشنهاد میشود:
۱. تعریف نقاط کنترل فرایند
برای هر فرایند مشخص کنید:
- شروع فرایند کجاست؟
- چه مراحلی اهمیت بیشتری دارند؟
- چه رویدادهایی باید ثبت شوند؟
- چه کسی مسئول هر مرحله است؟
۲. تعریف شاخصهای عملکردی (KPI)
برای مثال:
- متوسط زمان انجام فرایند
- تعداد درخواستهای برگشتی
- تعداد موارد تأخیرکرده
- زمان انتظار در هر مرحله
۳. ایجاد داشبوردهای مدیریتی
مدیران نباید برای فهم وضعیت فرایند منتظر گزارشهای دستی باشند.
یک داشبورد مناسب میتواند نشان دهد:
- چند درخواست در جریان است؟
- کدام مرحله بیشترین تأخیر را دارد؟
- عملکرد هر واحد چگونه است؟
۴. یکپارچهسازی اطلاعات
در فرایندهای سازمانی، معمولاً اطلاعات بین چند سیستم توزیع شده است. بنابراین باید مشخص شود:
- کدام سیستم مالک هر داده است؟
- اطلاعات چگونه بین سیستمها منتقل میشود؟
- چه کسی مسئول صحت دادههاست؟
مثال واقعی
در یک شرکت خدماتی، مشتریان مرتباً از طولانی بودن زمان پاسخگویی شکایت داشتند. مدیران تصور میکردند مشکل از کمبود نیروی انسانی است.
اما پس از تحلیل فرایند مشخص شد:
- مرحله بررسی اولیه فقط چند ساعت زمان میبرد.
- بیشترین تأخیر در انتظار تأیید یک واحد خاص ایجاد میشود.
- هیچ گزارشی از مدت توقف درخواستها در هر مرحله وجود نداشته است.
پس از ایجاد داشبورد پایش فرایند، مشکل اصلی مشخص شد و بدون افزایش تعداد کارکنان، زمان پاسخگویی کاهش یافت.
آنچه اندازهگیری نشود، قابل مدیریت و بهبود نیست.
۷. قراردادها و مشوقهای نامناسب؛
وقتی منافع افراد با اهداف فرایند هماهنگ نیست
مدیریت فرایند کسبوکار فقط درباره طراحی گردش کار و سیستم نیست؛ بلکه درباره هماهنگ کردن رفتار افراد و سازمانها برای رسیدن به یک نتیجه مشترک است.
یکی از مشکلاتی که کمتر مورد توجه قرار میگیرد، تأثیر قراردادها، ساختارهای ارزیابی عملکرد و مدلهای انگیزشی بر موفقیت BPM است.
ممکن است سازمان یک فرایند عالی طراحی کند، اما اگر شاخصهای عملکرد افراد برخلاف آن فرایند تعریف شده باشد، در عمل تغییر اتفاق نمیافتد.
برای مثال:
واحد خرید ممکن است بر اساس «کاهش قیمت خرید» ارزیابی شود، در حالی که هدف سازمان «کاهش زمان تأمین کالا» باشد.
در این حالت، کارشناس خرید ممکن است برای گرفتن قیمت پایینتر، مذاکرات طولانی انجام دهد؛ اما نتیجه آن افزایش زمان تأمین و توقف عملیات سازمان باشد.
مشکل از فرد نیست؛ مشکل از ناهماهنگی اهداف است.
چگونه قراردادها میتوانند مانع BPM شوند؟
در پروژههای سازمانی، گاهی قراردادها به شکلی طراحی میشوند که انعطاف لازم برای بهبود فرایند را از بین میبرند.
برخی نمونهها:
- پیمانکار فقط بابت تحویل یک نرمافزار پول دریافت میکند، نه بابت موفقیت فرایند.
- قراردادها بر اساس فعالیتهای انجام شده تنظیم شدهاند، نه نتیجه حاصلشده.
- تغییرات لازم برای بهبود فرایند به دلیل محدودیت قراردادی دشوار میشود.
- هر واحد سازمانی فقط اهداف خودش را دنبال میکند.
نشانههای این مشکل
- پیمانکار بیشتر به تحویل فنی توجه دارد تا نتیجه کسبوکار.
- واحدها حاضر نیستند روش کاری خود را تغییر دهند.
- بهبود فرایند باعث ایجاد تعارض با شاخصهای ارزیابی کارکنان میشود.
- هر بخش سازمان موفقیت را از زاویه خودش تعریف میکند.
پیامدها
- کاهش همکاری بین واحدها
- کند شدن اجرای تغییرات
- تمرکز بر فعالیتها به جای نتیجه
- از بین رفتن انگیزه بهبود مستمر
راهکارهای عملی
۱. شاخصهای مشترک تعریف کنید
به جای اینکه هر واحد فقط KPI خودش را داشته باشد، شاخصهای مشترک ایجاد کنید.
مثلاً در فرایند خرید:
- زمان کل خرید
- رضایت واحد درخواستکننده
- کیفیت تأمین
- هزینه نهایی
همه واحدهای درگیر باید در موفقیت این شاخصها سهیم باشند.
۲. قراردادها را نتیجهمحور کنید
در قراردادهای مربوط به پیادهسازی BPM، فقط تحویل نرمافزار یا مستندات نباید معیار موفقیت باشد.
باید مشخص شود:
- چه بهبودهایی انتظار میرود؟
- چه شاخصهایی باید تغییر کند؟
- مسئولیت هر طرف چیست؟
۳. منافع واحدها را با فرایند همراستا کنید
اگر بهبود یک فرایند باعث شود یک واحد احساس کند قدرت یا منابع خود را از دست میدهد، مقاومت طبیعی خواهد بود.
بنابراین مدیریت تغییر باید بخشی از پروژه باشد.
مثال واقعی
در یک سازمان، هدف پروژه کاهش زمان پرداخت به تأمینکنندگان بود. فرایند جدید طراحی شد، اما واحد مالی همچنان بر اساس تعداد کنترلهای انجام شده ارزیابی میشد.
کارکنان مالی برای حفظ امتیاز عملکرد خود، کنترلهای اضافی انجام میدادند و زمان پرداخت کاهش پیدا نکرد.
پس از اصلاح شاخصها و اضافه شدن معیار «زمان پرداخت»، رفتار واحد تغییر کرد و نتیجه مورد انتظار حاصل شد.
فرایند زمانی موفق میشود که ساختارهای سازمانی، قراردادها و انگیزهها نیز از آن پشتیبانی کنند.
۸. اتوماسیون قبل از بهبود فرایند؛ دیجیتال کردن مشکل به جای حل مشکل
یکی از رایجترین اشتباهات در پروژههای مدیریت فرایند کسبوکار این است که سازمانها تصور میکنند با خرید یک نرمافزار و تبدیل فعالیتهای دستی به الکترونیکی، فرایندهای آنها بهبود پیدا خواهد کرد.
در حالی که اتوماسیون، بهتنهایی باعث بهبود نمیشود.
اگر یک فرایند ناکارآمد را بدون تحلیل و اصلاح، خودکار کنیم، فقط همان مشکل را با سرعت بیشتری اجرا کردهایم.
به عبارت سادهتر:
اگر فرایند اشتباه را دیجیتال کنیم، یک فرایند اشتباه دیجیتال خواهیم داشت.
تفاوت بین دیجیتالی کردن و بهبود فرایند
این دو مفهوم اغلب با یکدیگر اشتباه گرفته میشوند.
دیجیتالی کردن (Digitalization)
یعنی تبدیل روش دستی به روش الکترونیکی.
مثلاً:
- تبدیل فرم کاغذی مرخصی به فرم آنلاین
- تبدیل امضای دستی به تأیید الکترونیکی
اما ممکن است همان مراحل اضافی، همان تأییدهای غیرضروری و همان قوانین قدیمی همچنان باقی بمانند.
بهبود فرایند (Process Improvement)
یعنی بررسی کنیم:
- چرا این مرحله وجود دارد؟
- آیا ارزش ایجاد میکند؟
- آیا میتوان آن را حذف کرد؟
- آیا مسئولیتها درست تعریف شدهاند؟
- آیا ترتیب فعالیتها منطقی است؟
پس از اصلاح فرایند، اتوماسیون معنا پیدا میکند.
چرا سازمانها دچار این اشتباه میشوند؟
دلایل مختلفی وجود دارد:
۱. جذابیت فناوری
دیدن یک نرمافزار جدید و امکانات آن معمولاً برای مدیران جذاب است. اما فناوری نباید جایگزین تحلیل مسئله شود.
۲. فشار برای رسیدن سریع به نتیجه
گاهی سازمانها به دنبال این هستند که سریعاً اعلام کنند:
«فرایند ما الکترونیکی شد.»
اما سرعت در شروع پروژه، اگر بدون تحلیل باشد، هزینه بیشتری در ادامه ایجاد میکند.
۳. تصور اینکه مشکل از نبود سیستم است
در بسیاری از سازمانها تصور اولیه این است:
«اگر یک سامانه داشته باشیم، مشکلات حل میشود.»
در حالی که بسیاری از مشکلات، ناشی از طراحی نامناسب فرایند، قوانین قدیمی یا نبود هماهنگی بین واحدها هستند.
نشانههای اتوماسیون اشتباه
- کاربران میگویند «سیستم کار ما را سختتر کرده است».
- تعداد مراحل در سیستم بیشتر از روش قبلی شده است.
- کارکنان همچنان خارج از سیستم کارها را پیگیری میکنند.
- فایلهای Excel و پیامهای شخصی همچنان استفاده میشوند.
- نرمافزار فقط نقش ثبتکننده اطلاعات را دارد، نه بهبوددهنده فرایند.
پیامدهای اتوماسیون بدون بهبود
افزایش پیچیدگی
فرایند پیچیده قبلی، اکنون در قالب یک سیستم پیچیده اجرا میشود.
کاهش پذیرش کاربران
کاربران احساس میکنند سیستم مانع کار آنهاست.
افزایش هزینه
سازمان هزینه نرمافزار، آموزش، پشتیبانی و توسعه را پرداخت میکند، اما ارزش مورد انتظار را دریافت نمیکند.
از دست رفتن فرصت بهبود
وقتی سازمان تصور کند «کار را دیجیتال کرده است»، ممکن است دیگر به فکر اصلاح واقعی فرایند نباشد.
راهکارهای عملی
ترتیب صحیح اجرای پروژه باید این باشد:
شناخت فرایند موجود
↓
تحلیل مشکلات و گلوگاهها
↓
طراحی فرایند مطلوب
↓
تعریف شاخصهای عملکرد
↓
اجرای آزمایشی
↓
اتوماسیون فرایند
↓
پایش و بهبود مستمر
قبل از هر اتوماسیون، این سؤالها را بپرسید:
- آیا این فعالیت واقعاً لازم است؟
- آیا این تأیید باید وجود داشته باشد؟
- آیا مسئولیتها درست تقسیم شدهاند؟
- آیا مشتری یا کاربر نهایی ارزش بیشتری دریافت میکند؟
- آیا راه سادهتری برای انجام این کار وجود دارد؟
مثال واقعی
در یک سازمان، فرایند درخواست مأموریت کارکنان بهصورت دستی انجام میشد. سازمان تصمیم گرفت آن را اتوماسیون کند.
در روش جدید:
- کارمند درخواست را در سیستم ثبت میکرد.
- مدیر آن را تأیید میکرد.
- منابع انسانی بررسی میکرد.
- مالی کنترل میکرد.
اما بررسی دقیق نشان داد دو مرحله از این گردش هیچ ارزش واقعی ایجاد نمیکند و فقط از گذشته باقی مانده است.
پس از حذف مراحل غیرضروری و سپس اتوماسیون، زمان انجام فرایند از چند روز به چند ساعت کاهش یافت.
مشکل اصلی نبود نرمافزار نبود؛ مشکل، طراحی فرایند بود.
۹. نبود مالک فرایند؛ فرایندی که صاحب ندارد، بهبود پیدا نمیکند
یکی از مهمترین اصول مدیریت فرایند کسبوکار این است که هر فرایند باید یک مالک مشخص (Process Owner) داشته باشد.
مالک فرایند فردی نیست که الزاماً همه فعالیتهای فرایند را انجام میدهد؛ بلکه کسی است که مسئول موفقیت، عملکرد و بهبود آن فرایند است.
برای مثال، در فرایند خرید:
- واحد تدارکات بخشی از فعالیتها را انجام میدهد.
- مالی کنترلهای مالی را انجام میدهد.
- مدیران درخواستها را تأیید میکنند.
- انبار دریافت کالا را ثبت میکند.
اما چه کسی مسئول است که کل فرایند خرید سریع، شفاف و کارآمد باشد؟
اگر پاسخ مشخصی وجود نداشته باشد، احتمالاً هیچکس مسئول واقعی نیست.
چرا نبود مالک فرایند مشکل ایجاد میکند؟
در ساختارهای سنتی، سازمان معمولاً بر اساس واحدها مدیریت میشود:
- مدیر مالی
- مدیر منابع انسانی
- مدیر فناوری اطلاعات
- مدیر فروش
اما مشتری و کسبوکار، نتیجه یک فرایند کامل را میبینند، نه عملکرد یک واحد خاص.
برای مثال، مشتری اهمیتی نمیدهد که تأخیر سفارش به دلیل مشکل فروش، انبار یا مالی بوده است. او فقط تجربه نهایی را ارزیابی میکند.
مالک فرایند باید نگاه بینواحدی داشته باشد و مسئول نتیجه کل مسیر باشد.
نشانههای نبود مالک فرایند
- هیچ فرد مشخصی پاسخگوی عملکرد کل فرایند نیست.
- مشکلات بین واحدها جابهجا میشوند.
- بهبودها فقط در یک واحد انجام میشوند.
- پس از پایان پروژه، کسی مسئول نگهداری مدلها نیست.
- KPI فرایند وجود ندارد یا کسی آن را پیگیری نمیکند.
پیامدها
توقف بهبود مستمر
پس از پایان پروژه، فرایندها به حال خود رها میشوند.
افزایش تعارض بین واحدها
هر واحد فقط مسئول بخش خودش میشود.
کاهش ارزش سرمایهگذاری BPM
سازمان هزینه تحلیل و پیادهسازی را پرداخت کرده، اما فرایند در طول زمان دوباره به وضعیت قبلی برمیگردد.
راهکارهای عملی
برای هر فرایند مهم سازمان:
۱. مالک مشخص تعیین کنید
مالک باید:
- اختیار تصمیمگیری داشته باشد.
- به اطلاعات فرایند دسترسی داشته باشد.
- بتواند بین واحدها هماهنگی ایجاد کند.
۲. مسئولیت مالک را شفاف کنید
مالک فرایند مسئول:
- عملکرد فرایند
- بررسی KPIها
- پیشنهاد بهبود
- هماهنگی تغییرات
- مدیریت نسخههای فرایند
است.
۳. فرایند را بخشی از نظام مدیریتی کنید
جلسات بررسی عملکرد فرایند باید مانند بررسی عملکرد مالی یا عملیاتی سازمان جدی گرفته شود
مثال واقعی
در یک سازمان، فرایند جذب نیروی انسانی چندین ماه طول میکشید. هر واحد مشکل را به واحد دیگری نسبت میداد:
منابع انسانی میگفت مشکل از تأیید مدیران است.
مدیران میگفتند مشکل از بررسی منابع انسانی است.
واحد فناوری اطلاعات نیز مشکل سامانه را مطرح میکرد.
پس از تعیین یک مالک فرایند برای کل چرخه جذب، مشخص شد بیشترین تأخیر در یک مرحله مشخص ایجاد میشود و با اصلاح همان مرحله، زمان جذب کاهش پیدا کرد.
فرایندی که مالک ندارد، معمولاً بعد از مدتی به فرایندی بدون مسئولیت تبدیل میشود.
۱۰. مسیر پیشنهادی جلوگیری از شکست پروژه BPM؛
چگونه احتمال موفقیت را افزایش دهیم؟
شناخت اشتباهات رایج BPM زمانی ارزشمند است که بتوانیم از آنها برای طراحی یک مسیر درست استفاده کنیم. بسیاری از سازمانها تصور میکنند موفقیت پروژه BPM به انتخاب نرمافزار مناسب یا انتخاب یک تیم متخصص محدود میشود؛ در حالی که موفقیت، نتیجه مجموعهای از تصمیمهای درست در طول مسیر است.
یک پروژه BPM موفق معمولاً از چند مرحله مشخص عبور میکند. حذف هر کدام از این مراحل میتواند ریسک شکست پروژه را افزایش دهد.
مرحله اول: مشخص کردن مسئله و هدف کسبوکار
قبل از هر اقدامی باید مشخص شود سازمان دقیقاً چه مشکلی را میخواهد حل کند.
شروع پروژه با سؤالهایی مانند موارد زیر ضروری است:
- کدام مشکل سازمانی باید حل شود؟
- این مشکل چه اثری بر هزینه، زمان یا رضایت مشتری دارد؟
- موفقیت پروژه چگونه اندازهگیری خواهد شد؟
- کدام فرایند بیشترین ارزش بهبود را ایجاد میکند؟
اشتباه رایج این است که سازمان با هدف کلی «اجرای BPM» پروژه را آغاز کند.
اما BPM هدف نیست؛ BPM یک روش برای رسیدن به اهداف کسبوکار است.
برای مثال:
هدف نامناسب:
پیادهسازی سیستم BPM در سازمان
هدف مناسب:
کاهش زمان پاسخگویی به درخواست مشتری از ۱۰ روز به ۳ روز از طریق بازطراحی و اتوماسیون فرایند خدمات
تفاوت این دو هدف، تفاوت بین یک پروژه فناوری و یک پروژه تحول کسبوکار است.
مرحله دوم: ایجاد حاکمیت و تعیین نقشها
پیش از شروع تحلیل فرایند، باید مشخص شود چه کسانی مسئول تصمیمگیری هستند.
حداقل نقشهای زیر باید مشخص شوند:
حامی اجرایی (Executive Sponsor)
فردی از مدیران ارشد که از پروژه حمایت میکند و موانع سازمانی را برطرف میسازد.
مالک فرایند (Process Owner)
مسئول عملکرد و بهبود یک فرایند مشخص.
مدیر پروژه BPM
مسئول هماهنگی فعالیتها، زمانبندی و ارتباط بین تیمها.
تحلیلگر فرایند (Process Analyst)
مسئول شناخت، مدلسازی و تحلیل فرایند.
کاربران کلیدی (Key Users)
نمایندگان افرادی که در اجرای واقعی فرایند مشارکت دارند.
نبود هر کدام از این نقشها میتواند پروژه را با مشکل مواجه کند.
مرحله سوم: شناخت وضعیت موجود (As-Is)
یکی از مهمترین مراحل BPM، شناخت دقیق روش فعلی انجام کار است.
در این مرحله نباید فقط به دستورالعملهای رسمی سازمان اعتماد کرد.
باید بررسی شود:
- کار واقعاً چگونه انجام میشود؟
- چه استثناهایی وجود دارد؟
- کجاها کار متوقف میشود؟
- چه فعالیتهایی ارزش ایجاد نمیکنند؟
- چه وابستگیهایی به افراد وجود دارد؟
ابزارهایی مانند:
- مصاحبه با کارکنان
- مشاهده مستقیم کار
- تحلیل دادههای سیستمها
- بررسی مستندات
- تحلیل زمان انجام فعالیتها
در این مرحله استفاده میشوند.
مرحله چهارم: طراحی وضعیت مطلوب (To-Be)
پس از شناخت وضعیت موجود، نوبت به طراحی فرایند بهتر میرسد.
در این مرحله باید پرسید:
- چه فعالیتهایی قابل حذف هستند؟
- چه کنترلهایی باید سادهتر شوند؟
- چه تصمیمهایی میتوانند سریعتر گرفته شوند؟
- چه فعالیتهایی قابلیت اتوماسیون دارند؟
هدف این مرحله فقط زیباتر کردن نمودار فرایند نیست؛ هدف، ایجاد یک روش بهتر برای انجام کار است.
مرحله پنجم: اجرای آزمایشی و بهبود
قبل از استقرار کامل، فرایند جدید باید در مقیاس محدود آزمایش شود.
در این مرحله باید بررسی شود:
- آیا کاربران میتوانند فرایند جدید را اجرا کنند؟
- آیا قوانین کسبوکار درست پیاده شدهاند؟
- آیا زمان انجام کار کاهش یافته است؟
- آیا مشکلات پیشبینینشده وجود دارد؟
بازخورد این مرحله باید قبل از اجرای گسترده در طراحی نهایی اعمال شود.
مرحله ششم: اتوماسیون و استقرار
پس از اطمینان از مناسب بودن طراحی فرایند، میتوان وارد مرحله انتخاب یا توسعه راهکار فناوری شد.
در این مرحله باید توجه شود که:
- فناوری باید از فرایند پشتیبانی کند.
- نه اینکه فرایند مجبور شود خود را با محدودیتهای فناوری تطبیق دهد.
مرحله هفتم: پایش و بهبود مستمر
یکی از بزرگترین اشتباهات این است که سازمان تصور کند با راهاندازی سیستم BPM، پروژه تمام شده است.
در واقع، اجرای BPM پایان مسیر نیست؛ آغاز یک چرخه دائمی بهبود است.
شرایط کسبوکار تغییر میکند:
- قوانین تغییر میکنند.
- نیاز مشتری تغییر میکند.
- فناوریهای جدید ایجاد میشوند.
- ساختار سازمان تغییر میکند.
بنابراین فرایندها نیز باید به صورت مستمر بررسی و بهبود داده شوند.
مسیر صحیح اجرای BPM در یک نگاه
۱۱. چکلیست ارزیابی آمادگی سازمان برای اجرای BPM
قبل از آغاز هر پروژه BPM، سازمان باید میزان آمادگی خود را ارزیابی کند.
به سؤالات زیر پاسخ دهید:
| سؤال | بله | خیر |
| آیا هدف مشخص کسبوکاری برای پروژه تعریف شده است؟ | □ | □ |
| آیا مدیر ارشد حامی پروژه مشخص شده است؟ | □ | □ |
| آیا مالک هر فرایند تعیین شده است؟ | □ | □ |
| آیا شاخصهای موفقیت پروژه مشخص هستند؟ | □ | □ |
| آیا کاربران اصلی در تحلیل فرایند مشارکت دارند؟ | □ | □ |
| آیا وضعیت فعلی فرایندها شناخته شده است؟ | □ | □ |
| آیا قبل از اتوماسیون، فرایندها بهبود داده میشوند؟ | □ | □ |
| آیا محیط آزمایشی برای اجرای پایلوت وجود دارد؟ | □ | □ |
| آیا برنامه آموزش و مدیریت تغییر وجود دارد؟ | □ | □ |
| آیا پس از استقرار، برنامه بهبود مستمر تعریف شده است؟ | □ | □ |
اگر پاسخ بسیاری از این سؤالات «خیر» باشد، بهتر است سازمان قبل از شروع پروژه اصلی، اقدامات آمادهسازی را انجام دهد.
BPM یک پروژه فناوری نیست، یک تغییر مدیریتی است
مدیریت فرایندهای کسبوکار زمانی موفق خواهد بود که سازمان نگاه خود را نسبت به نحوه انجام کارها تغییر دهد.
BPM فقط درباره:
- ترسیم نمودار فرایند،
- خرید نرمافزار،
- حذف فرمهای کاغذی،
- یا ایجاد گردش کار الکترونیکی
نیست.
BPM یعنی سازمان بتواند:
- بداند چگونه کار میکند،
- مشکلات خود را اندازهگیری کند،
- مسئولیتها را شفاف کند،
- تصمیمها را بر اساس داده بگیرد،
- و بهصورت مستمر عملکرد خود را بهبود دهد.
بسیاری از پروژههای BPM نه به دلیل ضعف فناوری، بلکه به دلیل نادیده گرفتن اصول ساده مدیریتی شکست میخورند:
- نبود حمایت مدیریت ارشد،
- هدف نامشخص،
- عدم مشارکت کاربران،
- انتخاب عجولانه ابزار،
- اتوماسیون فرایندهای نامناسب،
- نبود مالک فرایند،
- و نداشتن برنامه بهبود مستمر.
سازمانهایی که BPM را فقط یک پروژه کوتاهمدت میبینند، معمولاً پس از مدتی با همان مشکلات گذشته روبهرو میشوند. اما سازمانهایی که BPM را بهعنوان یک قابلیت مدیریتی دائمی میپذیرند، میتوانند چابکی، کیفیت خدمات و بهرهوری خود را بهصورت پایدار افزایش دهند.
در نهایت، مهمترین سؤال در یک پروژه BPM این نیست که:
« کدام نرمافزار را انتخاب کنیم؟ »
بلکه این است:
« چگونه میتوانیم بهتر کار کنیم و چگونه مطمئن شویم که این بهبود ادامه خواهد داشت؟ »
پاسخ درست به این سؤال، نقطه شروع یک سازمان فرایندمحور است.