اکثر سازمانها مجبورند با فرآیندها، پروژه ها و پرونده ها که چیزی بین این دو هستند، سر و کار داشته باشند. بنابراین آنها به یک دید متعادل و بی طرفانه در ارتباط با پروژه ها، فرآیندها و پرونده ها نیاز دارند که در اصل فقط انواع مختلفی از کارهای مشترک هستند. پروژه ها و پرونده ها، بیش از آن چیزی هستند که در نگاه اول به نظر میرسد: هر رویکردی که اتخاذ شود، همواره حالت اولیه، منابع و اهدافی وجود خواهند داشت که باید به آن برسیم.
با این وجود دشوار است که در زمینه های مختلف دانش متخصص باشید. میتوان یک تئوری را یاد گرفت، اما سالها طول میکشد تا در آن متخصص شد. به همین دلیل یافتن متخصصین پروژه یا فرآیند برای یک سازمان نسبتاً آسانتر است، اما این خطر وجود دارد که متخصصین اهمیت یک رویکرد را با توجه به هزینه رویکردهای دیگر، بیش از حد ارزیابی کنند.
صاحبان کسب و کارها، اغلب این رویکردها را اشتباه میگیرند. غیر معمول نیست که گفتگویی در مورد یک پروژه شروع شود و ناگهان به فرآیند تغییر کند و بالعکس. کار زمانی پیچیده تر میشود که افراد پروژه محور اغلب درباره فرآیندها بسیار صحبت میکنند – به عنوان مثال مجموعه دانش مدیریت پروژه (PMBOK) بیشتر در مورد فرآیندهای حاکم بر برنامه ریزی، اجرا و کنترل پروژهها است تا در مورد خود پروژه ها. با این وجود نحوه تعریف PMBOK از یک فرآیند با تعریف ارائه شده در مجموعه دانش مدیریت فرآیند کسب و کار (BPM CBOK) تفاوت قابل توجهی دارد.
در نهایت پروژه ها، فرآیندها و پرونده ها فقط روشهای مختلفی برای حل مسائلی هستند که هر سازمان متوسط و بزرگی با آنها روبرو هستند؛ یعنی: “طرز فکر سیلویی” و شکاف بین اهداف واحدهای کسب و کار و اهداف سازمان. مشکل اصلی این مسائل تقسیم کار است. کسب و کارها باید به هر روشی این مسائل را حل کنند. این روش ممکن است مدیریت پروژه یا مدیریت فرآیند باشد اما روشهای دیگری همچون مدیریت پرونده های سازگار / پویا، گردش کار مستند گرا، پیگیری مسئله… نیز وجود دارد و انتخاب رویکرد مناسب کمی گیج کننده به نظر میرسد.
هدف این مقاله موارد زیر است:
- کمک به انتخاب بهترین رویکرد (یا ترکیبی از رویکردها) برای کارهای مشارکتی بسته به مشخصات سازمان.
- فراهم نمودن درک اساسی از ابزارهای نرم افزاری موجود که از این رویکردها پشتیبانی میکنند.
- تجزیه و تحلیل تفاوتها و شباهت های بین این روشها و تعریف چشم اندازی از یک محصول نرم افزاری یکپارچه که همه آنها را اجرا میکند.
دو بحث اول جدید نیستند اما امیدواریم برای خوانندگان مفید باشند. بخش سوم براساس تحقیقاتی است که هم اکنون در Comindware انجام شده است.
شکلهای مختلف کار مشترک
ما فقط کار تیمی را در نظر گرفته و کارهای انجام شده توسط یک فرد را در نظر نخواهیم گرفت. اصل کار را نیز در نظر نگرفته و فقط جنبههای هماهنگی کار تیمی مدنظر است.
تعاریف:
- پروژه دنبالهای از فعالیتها است که به دنبال یک برنامه مشخص و با هدف ارائه نتیجه، محصول یا خدمات منحصر به فرد میباشد. مثال: راه سازی.
توجه: “تعریف شده” در اینجا و در زیر به معنی “تعریف شده قبل از شروع کار” است. در مقابل، “برخی” به معنای “تعریف شده در طول کار” است.
- فرآیند به معنی یک توالی تعریف شده و تکراری از فعالیت های آغاز شده توسط یک رویداد مشخص و تولید یک نتیجه، محصول یا خدمات از پیش تعریف شده است. مثال: پردازش سفارش مشتری.
توجه: اصطلاحات “فرآیند” و “فرآیند کسب و کار”، “فعالیت” و “کار” در اینجا به عنوان مترادف استفاده میشوند.
- پرونده، به معنی برخی از توالی فعالیت هایی است که با هدفی از پیش تعریف شده انجام میشوند. مثال: معالجه بیمار در بیمارستان، پرونده قضایی.
- Docflow (گردش کار مستند گرا) دنبالهای از پیش تعریف شده در مورد فعالیتهای مربوط به یک سند خاص است. مثال: تأیید قرارداد، پردازش نامه ورودی.
- مورد، یک رویداد مشخص است که باید توسط برخی از توالی فعالیت ها برای رسیدن به نتیجه مشخص انجام شود. مثال: کامنتهای ارسالی به پشتیبانی
طبقه بندی خصوصیات کارهای مشترک
مرزهای بین اشکال مختلف کارهای مشارکتی، اغلب مبهم است. به عنوان مثال، توسعه محصول جدید بسته به صنعت، نوع محصول و فرهنگ سازمان ممکن است به عنوان یک پروژه، فرآیند، پرونده یا حتی Docflow در نظر گرفته شود. با این وجود، ممکن است با توجه به جنبههای زیر متفاوت شوند:
- قابل تکرار. آیا میتوان توالی فعالیتها را دسته بندی کرد؟ به عنوان مثال، به چندین نمونه نام مشترکی بدهیم. برای فرآیندها، پرونده ها و Docflow ها پاسخ مثبت است. پروژه ها و موردها به طور کلی قابل تکرار نیستند (اگرچه پروژه ها و موردهای تکراری ممکن است اتفاق بیفتد).
- قابل پیش بینی. آیا میتوان توالی فعالیتها را از قبل تعریف کرد یا اینکه “در حال اجرا” تعیین میشوند؟ به طور کلی پرونده ها، docflow ها و موارد، قابل پیش بینی نیستند. یک پرونده “برای اولین بار راه اندازی” میشود؛ به این ترتیب که فعالیتهای بعدی از فعالیت هایی که قبلاً انجام شده اند حاصل میشوند. همچنین یک سند در یک سیستم docflow معمولی ممکن است در هر مرحله مجدداً پردازش شود. در مقابل، یک فرآیند کاملاً قابل پیش بینی است: اگرچه ممکن است درگاه هایی با چند نتیجه احتمالی وجود داشته باشند، اما همه گزینه ها و شرایط از قبل مشخص هستند. یک پروژه نیز قابل پیش بینی است – برنامه پروژه شامل لیست کاملی از وظایف است. درجهای از غیرقابل پیش بینی بودن وجود دارد؛ زیرا ممکن است با پیشرفت پروژه، طرح پروژه اصلاح شود، اما پروژه ها به طور معمول قابل پیش بینی در نظر گرفته میشوند.
- ساختاریافته. آیا میتوان ورودی و خروجی کار را با داده های ساختاریافته توصیف کرد؟ فرآیندها و پرونده ها با داده های ساختاریافته سروکار دارند: اعداد، مقادیر، تاریخها، منابع، و غیره. پروژه ها و موردها با داده های ساختار نیافته سروکار دارند. موارد بالا را در جدول به طور خلاصه بیان کنیم:
جدول فوق نشان میدهد که فرآیندها و موضوعات دو قطب هستند: فرآیندهای قابل تکرار، قابل پیش بینی و ساختاریافته و موردهای منحصر به فرد، غیرقابل پیش بینی و بدون ساختار. اشکال دیگر در جایی بین این دو قرار دارند.
چارچوب کارهای مشارکتی
در نگاه اول، ممکن است به نظر برسد که علامتهای تیک در جدول ۱ به طور تصادفی قرار گرفته اند. از ویژگیهای طبقه بندی به عنوان محور بعدی استفاده کرده و سیستمی از آن ایجاد میکنیم. بیایید با “قابل تکرار” و “ساختار یافته” شروع کنیم:
شکل ۱ همبستگی کار ساختار یافته و قابل تکرار را نشان میدهد. لازم به ذکر است که گرچه فرآیندها و پرونده ها میتوانند با داده های ساختاریافته کار کنند، اما میتوانند محتوای بدون ساختار را نیز پردازش نمایند. کار با داده های ساختاریافته دارای مزایای مشخصی است:
- تایید. هرچند که میتوان هر اطلاعاتی را در یک سند متنی وارد کرد، اما اطلاعات ورودی به یک فیلد صفحهای که به ستون جدول پایگاه داده متصل است میتواند کاملاً بررسی و تأیید شود. به عنوان مثال. تاریخ پرواز برگشت که دیرتر از تاریخ پرواز رفت است.
- امکان ادغام با سیستمهای سازمانی. به عنوان مثال اگر گزارش هزینه به عنوان یک پرونده متنی ارسال شود، پردازش آن به صورت دستی و مستعد خطا خواهد بود. اما همان گزارش که توسط یک نرم افزار مدیریت فرآیند کسب و کار پیاده سازی شده، از ساختار مناسبی برخوردار خواهد بود و انتقال گزارش به سیستم حسابداری، کپی برداری از یک پایگاه داده به پایگاه دیگر است.
گردش کار مستند گرا در شکل ۱ مانند یک استثنا به نظر میرسد: قابل تکرار و در عین حال بدون ساختار. رویکرد docflow اغلب به این دلیل مورد انتقاد قرار میگیرد که کاری جز این نکرده که اسناد دستی را با اسناد الکترونیکی جایگزین نموده است. اگر ساختار بر روی اطلاعات اعمال شود، میتوان ارزش بیشتری تولید نمود. جای تعجب نیست که پیچیدگی ادغام با سیستمهای سازمانی ضعف شناخته شده سیستمهای docflow است.
با توجه به پروژهها و موردها، هنگام کار با کارهایی کاملاً منحصر به فرد، اطلاعات بدون ساختار خواهند بود و این امری اجتناب ناپذیر است. اما اگر ما کار غیر منحصر به فرد و تکراری را به جای پرونده یا پردازش، به عنوان پروژه یا مسئله در نظر بگیریم، مزایای پردازش دادههای ساختاریافته از بین میرود. حال بیایید به محورهای قابل تکرار / قابل پیش بینی نگاهی بیندازیم:
همه سلولها پر شده است، فقط اسناد و پروندهها با هم همپوشانی دارند. در واقع، نرم افزار مدیریت پرونده و docflow از اقوام نزدیک یکدیگر هستند. با ظهور ACM برخی از فروشندگان ECM محصولات خود را دوباره با عنوان ACM برچسب گذاری کردند.
انتظار میرود که در آینده نرم افزار ACM به طور کامل جایگزین docflow شود؛ زیرا این نرم افزار قادر به پردازش هر دو نوع دادههای بدون ساختار و ساختاریافته است. از طرف دیگر، امروزه نرم افزار docflow به طور کلی بالغتر است.
شکل ۳ ماتریس کامل را با ترکیب غیر منطقی “قابل تکرار + بدون ساختار” (اسناد) نشان داده است:
شکلهای خالص و مختلط کار
در واقعیت، کارهای صرفاً پروژه ای یا فرآیندی نادر هستند و معمولاً ترکیبی از کارها وجود دارد. پروژه ها، فرآیندها، موردها در طول زمان ۱) یکدیگر را فراخوانی کرده و ۲) تبدیل به یکدیگر میشوند. چند نمونه:
- عملیات پشتیبانی IT اغلب به عنوان یک کار فرآیندی مورد بررسی قرار میگیرد: خطوط پشتیبانی اول و دوم معرفی میشوند، SLA و ارجاع به مراتب بالاتر ایجاد میشوند و غیره. با این حال این امر فقط در مورد کنترل است. کار فیزیکی که باید برای حل یک مورد انجام شود، تقریباً هر کاری میتواند باشد و بنابراین باید به عنوان یک پرونده ارائه گردد. در اینجا فرآیندی که اجرا میشود، یک پرونده است.
- مدیریت پروژه کلاسیک از الگوی مشابهی پیروی میکند: شروع پروژه، تعطیلی پروژه، برنامه ریزی مجدد پروژه ممکن است به عنوان فرآیند کاملاً مشخصی که پروژه را اجرا یا با آن ارتباط برقرار میکند، ارائه شود.
- یک بیمار در اورژانس بیمارستان یک مثال مخالف است. ارائه خدمات پزشکی به عنوان یک فرآیند به سختی امکانپذیر است؛ زیرا موارد بسیاری وجود دارد که پیش بینی آنها دشوار خواهند بود. از این رو سطوح بالا، یک پرونده محسوب میشوند. اما در سطوح پایینتر، درمانها و آزمایش هایی وجود دارد که به خوبی میتوان آنها را به عنوان فرآیندها تعریف نمود. در اینجا با یک پرونده روبرو هستیم که یک سری فرآیندها را اجرا میکند.
- یک سازمان ممکن است یک کار مشارکتی که اساساً یک فرآیند است (بسیار قابل پیش بینی و قابل تکرار) را به عنوان یک پروژه یا کار موردی تلقی کند؛ زیرا مدلسازی یک فرآیند به مهارت، تلاش و زمان نیاز دارد. به عنوان مثال، یک شرکت داروسازی سالهاست که تولید داروی جدیدی را به عنوان یک پروژه مد نظر قرار داده و سپس، هنگامی که “دستور العمل” این کار مشخص شد، به صورت یک فرآیند مدنظر قرار میگیرد.
متأسفانه اکثر ابزارهای موجود فقط از یک شکل کار مشارکتی پشتیبانی میکنند و بنابراین از قابلیت تعامل پذیری و تحول پشتیبانی نمینمایند. این امر فضایی برای ظهور نسل جدیدی از ابزارهای یکپارچه که انواع کارهای مشارکتی را با هر ترکیبی پشتیبانی میکنند، ایجاد مینماید.
