متدولوژی عملیاتی BPM - قسمت چهارم

در قسمت سوم این مطلب، فاز دوم متدولوژی عملیاتی BPM ارائه گردید. در این مطلب فاز ۳ یعنی تجزیه و تحلیل (Analyze) ارائه می شود.

 

فاز 3: تجزیه و تحلیل (Analyze) 

چهار فاز بعدی بیانگر نمای کلی پروژه ی BPM است. هر پروژه ی BPM ای شامل این چهار فاز می باشد. هر بار که یک پروژه کامل می شود (طراحی و اجرای یک فرآیند کامل می شود)، تیم اجرای فرآیند می تواند یک فرآیند جدید را آغاز کرده و این چهار فاز را دوباره طی نماید.

این فاز شامل برنامه ریزی پروژه و تجزیه و تحلیل فرآیند می شود. ورودی این فاز، لیست فرآیندهایی است که توسط واحد اجرای فرآیند برای پیاده سازی انتخاب شده اند و زمان لازم برای پیاده سازی آن نیز تخمین زده شده است. در این فاز تیم پروژه باید منشور پروژه را تهیه کنند و فرآیندهای موجود را با در نظر گرفتن محدوده ی پروژه تجزیه و تحلیل کنند. ما در این بخش به نحوه ی برپایی تیم پروژه، منشور پروژه و تجزیه و تحلیل فرآیند می پردازیم. موارد زیر، خلاصه ی کلیه ی وظایفی که در این فاز مطرح می شود را بیان می کند:

جمع آوری تیم پروژه:

  • رهبران تغییر و اعضاء اصلی تیم در پروژه مستقر شوند.
  • کمیته ی راهبری پروژه تشکیل گردد.
  • درگیر کردن ذینفعان پروژه.

 

تهیه منشور پروژه:

  • مشکلات فرآیند، محدوده ی پروژه، اهداف پروژه، نقش ها و مسئولین، برنامه ریزی کلان پروژه و مفروضات پروژه مشخص شوند.
  • تاییدیه ی منشور پروژه از کمیته ی راهبری و ذینفعان پروژه دریافت گردد.

 

انجام تجزیه و تحلیل فرآیندها:

  • داده های فرآیندی موجود در محدوده ی پروژه دریافت گردد.
  • برای دستیابی به میزان کارایی فرآیندهای موجود، داده های دریافت شده تجریه و تحلیل گردد.
  • چالش های فرآیندهای جاری مستند شوند.

 

در ادامه به تشریح به هر یک از موارد بالا می پردازیم.

 

جمع آوری تیم پروژه:

یک تیم پروژه باید حداقل شامل اعضاء زیر باشد:

  • مدیر پروژه
  • مسئول تغییرات کسب و کار
  • توسعه دهنده و تیم پشتیبان تکنولوژی

شکل زیر تیم های درگیر در پروژه را نمایش می دهد:

 

مسئولیت تمامی دستاوردها و شکست ها با مدیر پروژه است. بهترین حالت زمانی است که تنها یک مدیر پروژه وجود داشته باشد تا در انتها یک شخص پاسخگو باشد. مسئولیت های مدیر پروژه شامل موارد زیر است:

  • تهیه ی برنامه ی پروژه
  • هماهنگی تیم های درگیر در پروژه
  • کسب مشارکت از ذینفعان
  • همراه ساختن کمیته ی راهبری پروژه

تمامی افرادی که تحت تاثیر اجرای پروژه قرار می گیرند ذینفع پروژه محسوب می گردند. ذینفع می تواند مدیر یک واحد باشد - به علت درگیری در پروژه ی BPM - یا واحد فناوری اطلاعات باشد زیرا وظیفه ی پشتیبانی از سیستم را به عهده دارد یا کاربران باشند زیرا برای انجام روش جدید کارشان نیاز به آموزش دارند. کمیته ی ذینفعان از مدیران ارشد هر واحد کسب و کار تشکیل شده است که برای این پروژه گرد هم آمده اند.

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

سوالی که مطرح می شود این است که تفاوت رهبران تغییر با اعضاء اصلی تیم در چه چیز است؟

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

دیگر اعضاء تیم تغییر شامل کارشناسان طراحی فرآیند و چارت سازمانی هستند. کارشناسان طراحی چارت سازمانی وظیفه دارند که چارت سازمانی را از جنبه ی عملکرد بهینه ی فرآیندها مورد تجزیه و تحلیل قرار دهند. این امر گاهی اوقات ممکن است به تغییرات در چارت سازمانی منتهی شود که در نهایت تغییرنقش ها و شغل های افراد را به دنبال دارد. کارشناسان طراحی چارت سازمانی نقش ها و مسئولیت های این شغل های بوجود آمده را باید مشخص کنند و علاوه بر آن اهداف فرآیندها و پاداش دستیابی به این اهداف را نیز باید مشخص کنند. در این حین کارشناسان طراحی فرآیند به تجزیه و تحلیل فرآیندهای کسب و کار جاری می پردازند و مطابق اصول BPM آن ها را بازطراحی می کنند. کارشناسان طراحی فرآیندها - در حین متدولوژی BPM - طراحی و شبیه سازی فرآیند با ابزار BPMS را آموزش می بینند. در واقع مسئولیت اصلی تیم طراحی این است که سناریوهای فرآیندی را از سایر تیم های پروژه دریافت کنند و مطابق تکنیک های طراحی فرآیند، مناسب ترین فرآیند در حوزه ی پروژه را طراحی کنند. (برای کسب اطلاعات بیشتر در مورد تکنیک های طراحی فرآیند، می توانید از این منبع استفاده کنید).

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

تیم توسعه باید شامل: طراح وب، توسعه دهنده وب، معمار برنامه ی کاربردی سازمان، توسعه دهندگانی که کار با ابزار BPMS را آموزش دیده اند و توسعه دهندگان سیستم های قبلی (که در این پروژه مطرح می شوند) سازمان باشند. البته با وجود این سمت ها در تیم ممکن است توسعه دهندگانی باشند که بتوانند چندین سمت را به عهده گیرند و تعداد افراد، کمتر از تعداد سمت ها باشد. تفاوت مشهودی بین توسعه دهنده و طراح وب است. طراح وب ظاهر وب سایت را آماده سازی می کند در حالی که توسعه دهنده با برنامه نویسی سمت سرور، وب سایت را کنترل می کند. 

معمار برنامه کاربردی، مدل ماژول های موجود در حوزه ی پروژه را تهیه می کند. اطمینان از امکان استفاده ی مجدد از برنامه های کاربردی قبلی- که در حوزه ی پروژه هستند - و نظارت بر برنامه های کاربردی که در آینده طراحی خواهند شد از وظایف معمار برنامه های کاربردی می باشد. وظیفه ی دیگر او کسب اطمینان از رعایت کردن استانداردهای پروژه ی BPM توسط برنامه های کاربردی سازمان است زیرا اکثر برنامه های کاربردی در سازمان ها از واسط های مناسبی برای برقراری ارتباط با BPMS ها برخوردار نیستند. بنابراین توسعه دهندگانی که با این سیستم های سازمانی آشنایی دارند باید در تیم توسعه ی پروژه همکاری داشته باشند تا از برقراری ارتباط میان این سیستم ها با ابزار BPMS اطمینان حاصل گردد.

آخرین تیم در پروژه، تیم پشتیبان تکنولوژی است. این تیم وظایف مدیر سیستم و بهینه سازی عملکرد سیستم را بر عهده دارد که برای دستیابی به موفقیت در پروژه های بزرگ، وجود یک تیم اختصاصی پشتیبانی الزامی است. تاخیر در زمانبندی چنین پروژه هایی، به ضررهای مالی بزرگی می تواند منجر شود. اعضاء تیم پشتیبان تکنولوژی این تضمین را می دهند که عامل به تاخیر افتادن پروژه، مرتبط با موارد تکنولوژی نباشد. جدای از اندازه ی پروژه، آن ها برای زمان پاسخ گویی خدمات با دیگر تیم های پروژه به توافق می رسند و بر اساس این موافقت نامه ی سطح خدمت (SLA)، در فازهای حساس پروژه مناسبترین پشتیبانی را انجام می دهند.

 

تهیه منشور پروژه:

قدم بعدی پس از گردآوری تیم، تهیه ی منشور پروژه است (می توانید یک نمونه از منشور پروژه را از این منبع دانلود کنید). منشور پروژه، مبنای پروژه ی BPM است که شامل موارد زیر است:

  • مشکلات فرآیندی
  • محدوده ی پروژه
  • اهداف اجرایی پروژه
  • نقش ها و مسئولیت ها
  • برنامه ریزی کلان
  • فرضیات پروژه

مفهوم منشور پروژه در BPM بسیار مشابه این مفهوم در متدولوژی شش سیگما است.

در بخش مشکلات فرآیندی، وضعیت (یا کمبودها) فرآیندهای جاری و چالش های کسب و کار مستند می گردد.

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

برای دستیابی به اهداف اجرایی پروژه نیازمند این هستیم که تیم های متنوعی انتظارات خود را بصورت کلی از پروژه بیان کنند. این اهداف بصورت کلی بوده و در فاز طراحی به جزء بیان خواهند شد، ولی در این مرحله تمامی انتظارات بدست آمده باید در منشور پروژه بیان شوند. در انتها تمامی نقش ها و مسئولیت های درگیر در پروژه (که از تیم های ذینفعان، کاربران کسب و کار و کمیته ی راهبری پروژه دریافت شده است) و زمانبندی مرتبط با آن ها در منشور پروژه ثبت می گردد. زمانبندی که در منشور پروژه مطرح می گردد یک زمانبندی کلی است که بر اساس تجربه های پیشین انتخاب شده و در فاز طراحی مورد بازبینی قرار می گیرد.

هدف اصلی از تهیه ی منشور پروژه برقرای ارتباط مابین تمامی بخش های درگیر در پروژه است. منشور پروژه به امضاء کمیته ی راهبری و ذینفعان پروژه می رسد. پس از تایید منشور پروژه، اعضاء می توانند از آن به عنوان یک حکم برای رسمیت شناختن ماهیت پروژه و اقدامات مرتبتشان استفاده کنند.

 

تجزیه و تحلیل فرآیندها:

لازم است که در حین آماده سازی منشور پروژه، تیم پروژه تجزیه و تحلیل فرآیندهای جاری سازمان را انجام دهد. قسمتی از این اطلاعات بصورت کلان در فاز جستجو جمع آوری شده است ولی در مرحله ی تجزیه و تحلیل، این اطلاعات با هدف دستیابی به میزان کارایی فرآیندهای موجود به تفصیل شرح داده می شود. دست یابی به داده های فرآیندهای در حال اجرا کار ساده ای نیست زیرا ممکن است داده ی قابل استناد وجود نداشته باشد یا اینکه به راحتی نتوان به آن دست یافت.

اگر در یک فرآیند، سیستم هایی از قبل وجود دارند که وقایع را ثبت می کنند، از این وقایع ثبت شده می توان برای ارزیابی مدت زمان فعالیت ها استفاده کرد. برخی اوقات که ثبت وقایع سیستمی وجود ندارد می توان با استفاده از اندازه گیری غیر مستقیم میانگین مدت زمان فعالیت ها را بدست آورد، بدین ترتیب که مدت زمان انجام کلیه تراکنش ها را بر تعداد تراکنش های انجام شده در آن دوره ی زمانی تقسیم کنیم.

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

ادامه در متدولوژی عملیاتی BPM - قسمت پنجم


نویسنده:  James F.Chang

منبع: کتاب Business Process Management System - فصل ۱۰

ترجمه: سهیل نیک فرجام


 

درباره رایورز

شرکت مهندسی نرم‌افزار رایورز در اوایل سال 1368 توسط جمعی‌از فعالین حرفه نرم‌افزار تأسیس گردید...

بیشتر بدانید

ارتباط با ما

  • تهران، خيابان ولی عصر، نرسيده به توانير، خيابان احتشام، شماره 5
  • 89326000

  • BPMS@rayvarz.com

خبرنامه پایگاه دانش BPM