در قسمت سوم این مطلب، فاز دوم متدولوژی عملیاتی BPM ارائه گردید. در این مطلب فاز ۳ یعنی تجزیه و تحلیل (Analyze) ارائه میشود.
فاز 3: تجزیه و تحلیل (Analyze)
چهار فاز بعدی بیانگر نمای کلی پروژهی BPM است. هر پروژهی BPM ای شامل این چهار فاز میباشد. هر بار که یک پروژه کامل میشود (طراحی و اجرای یک فرآیند کامل میشود)، تیم اجرای فرآیند میتواند این چهار فاز را دوباره طی نماید.
این فاز شامل برنامهریزی پروژه و تجزیه و تحلیل فرآیند میشود. ورودی این فاز، لیست فرآیندهایی است که توسط واحد اجرای فرآیند برای پیاده سازی انتخاب شدهاند و زمان لازم برای پیادهسازی آن نیز تخمین زده شده است. در این فاز تیم پروژه باید منشور پروژه را تهیه کنند و فرآیندهای موجود را با در نظر گرفتن محدودهی پروژه تجزیه و تحلیل کنند. ما در این بخش به نحوهی برپایی تیم پروژه، منشور پروژه و تجزیه و تحلیل فرآیند میپردازیم. موارد زیر، خلاصهی کلیهی وظایفی که در این فاز مطرح میشود را بیان میکند:
جمعآوری تیم پروژه:
تهیه منشور پروژه:
انجام تجزیه و تحلیل فرآیندها:
در ادامه به تشریح به هر یک از موارد بالا میپردازیم.
جمع آوری تیم پروژه:
یک تیم پروژه باید حداقل شامل اعضاء زیر باشد:
مسئولیت تمامیدستاوردها و شکستها با مدیر پروژه است. بهترین حالت زمانی است که تنها یک مدیر پروژه وجود داشته باشد تا در انتها یک شخص پاسخگو باشد. مسئولیتهای مدیر پروژه شامل موارد زیر است:
تمامیافرادی که تحت تاثیر اجرای پروژه قرار میگیرند ذینفع پروژه محسوب میگردند. ذینفع میتواند مدیر یک واحد باشد – به علت درگیری در پروژهی BPM – یا واحد فناوری اطلاعات باشد زیرا وظیفهی پشتیبانی از سیستم را به عهده دارد یا کاربران باشند زیرا برای انجام روش جدید کارشان نیاز به آموزش دارند. کمیتهی ذینفعان از مدیران ارشد هر واحد کسب و کار تشکیل شده است که برای این پروژه گرد هم آمدهاند.
تیم تغییرات کسب و کار، مسئولیت هدایت طراحی فرآیندهای کسب و کار و هم محور سازی سازمان را برعهده دارند. این تیم باید شامل رهبران تغییر، اعضاء اصلی تیم، کارشناسان طراحی چارت و کارشناسان طراحی فرآیند باشد. رهبران تغییر باید تیم تغییرات کسب و کار را رهبری کنند و همچنین واحدهایی را که تحت تاثیر تغییرات قرار گرفته اند را با شرایط جدید وفق دهند. اعضاء اصلی تیم، شامل نمایندگانی از واحدهای کسب و کارند که با نحوهی اجرای فرآیندهای جاری به خوبی آشنا هستند. این افراد باید مورد احترام و اعتماد واحد سازمانی خود باشند و همچنین در ماهیت پروژه شک و تردیدی نداشته باشند تا بتوانند ارتباطی قوی در رابطه با پروژه با باقی افراد سازمان برقرار کنند در غیر این صورت بازخورد منفی بوجود خواهد آمد.
سوالی که مطرح میشود این است که تفاوت رهبران تغییر با اعضاء اصلی تیم در چه چیز است؟
اعضاء اصلی تیم از لحاظ موقعیت سازمانی به بطن کار بسیار نزدیک هستند، آنها درک خوبی از چگونگی نحوهی اجرای فرآیندهای بخش خود دارند. در صورتی که رهبران تغییر به طور معمول ردهی بالاتری در چارت سازمانی دارند و علاوه بر رهبری کردن تغییرات کسب و کار، با مدیران سطوح میانی و بالاتر در تعامل هستند.
دیگر اعضاء تیم تغییر شامل کارشناسان طراحی فرآیند و چارت سازمانی هستند. کارشناسان طراحی چارت سازمانی وظیفه دارند که چارت سازمانی را از جنبه ی عملکرد بهینهی فرآیندها مورد تجزیه و تحلیل قرار دهند. این امر گاهی اوقات ممکن است به تغییرات در چارت سازمانی منتهی شود که در نهایت تغییرنقشها و شغلهای افراد را به دنبال دارد. کارشناسان طراحی چارت سازمانی نقشها و مسئولیتهای این شغلهای بوجود آمده را باید مشخص کنند و علاوه بر آن اهداف فرآیندها و پاداش دستیابی به این اهداف را نیز باید مشخص کنند. در این حین کارشناسان طراحی فرآیند به تجزیه و تحلیل فرآیندهای کسب و کار جاری میپردازند و مطابق اصول BPM آنها را بازطراحی میکنند. کارشناسان طراحی فرآیندها – در حین متدولوژی BPM – طراحی و شبیهسازی فرآیند با ابزار BPMS را آموزش میبینند. در واقع مسئولیت اصلی تیم طراحی این است که سناریوهای فرآیندی را از سایر تیمهای پروژه دریافت کنند و مطابق تکنیکهای طراحی فرآیند، مناسبترین فرآیند در حوزهی پروژه را طراحی کنند.
پشتوانهی تیم تغییر، تیمهای توسعه و پشتیبان تکنولوژی هستند. تیم توسعه شامل برنامه نویسهایی است که طراحی فرآیندهای کسب و کار را پشتیبانی میکنند. شرکتهای ارائه دهندهی BPMS در تبلیغات این گونه میگویند که “محصولشان بصورت خودکار کدنویسی انجام میدهد” بر این اساس برخی از شرکتها تا آنجا پیش میروند که محصول خود را “راهکار بدون نیاز به کد نویسی” معرفی میکنند. در حقیقت کدنویسی برای تمامیابزارهای BPMS لازم است مگر اینکه فرآیند را به فرمهای ساده، واسط میانی، رابط کاربری ساده و بهرهگیری از ماژولهای آماده محدود کنیم. همچنان برای پیادهسازیهای پیچیده مانند قوانین، واسطهای کاربری و تغییرات در ماژولها نیازمند توسعه دهنده هستیم.
تیم توسعه باید شامل: طراح وب، توسعهدهنده وب، معمار برنامهی کاربردی سازمان، توسعهدهندگانی که کار با ابزار BPMS را آموزش دیده اند و توسعهدهندگان سیستمهای قبلی (که در این پروژه مطرح میشوند) سازمان باشند. البته با وجود این سمتها در تیم ممکن است توسعه دهندگانی باشند که بتوانند چندین سمت را به عهده گیرند و تعداد افراد، کمتر از تعداد سمتها باشد. تفاوت مشهودی بین توسعهدهنده و طراح وب است. طراح وب ظاهر وب سایت را آمادهسازی میکند در حالی که توسعهدهنده با برنامه نویسی سمت سرور، وب سایت را کنترل میکند.
معمار برنامه کاربردی، مدل ماژولهای موجود در حوزهی پروژه را تهیه میکند. اطمینان از امکان استفادهی مجدد از برنامههای کاربردی قبلی- که در حوزهی پروژه هستند – و نظارت بر برنامههای کاربردی که در آینده طراحی خواهند شد از وظایف معمار برنامههای کاربردی میباشد. وظیفهی دیگر او کسب اطمینان از رعایت کردن استانداردهای پروژهی BPM توسط برنامههای کاربردی سازمان است زیرا اکثر برنامههای کاربردی در سازمانها از واسطهای مناسبی برای برقراری ارتباط با BPMSها برخوردار نیستند. بنابراین توسعهدهندگانی که با این سیستمهای سازمانی آشنایی دارند باید در تیم توسعه ی پروژه همکاری داشته باشند تا از برقراری ارتباط میان این سیستمها با ابزار BPMS اطمینان حاصل گردد.
آخرین تیم در پروژه، تیم پشتیبان تکنولوژی است. این تیم وظایف مدیر سیستم و بهینه سازی عملکرد سیستم را بر عهده دارد که برای دستیابی به موفقیت در پروژههای بزرگ، وجود یک تیم اختصاصی پشتیبانی الزامیاست. تاخیر در زمانبندی چنین پروژههایی، به ضررهای مالی بزرگی میتواند منجر شود. اعضاء تیم پشتیبان تکنولوژی این تضمین را میدهند که عامل به تاخیر افتادن پروژه، مرتبط با موارد تکنولوژی نباشد. جدای از اندازهی پروژه، آنها برای زمان پاسخ گویی خدمات با دیگر تیمهای پروژه به توافق میرسند و بر اساس موافقت نامهی سطح خدمت (SLA)، در فازهای حساس پروژه مناسبترین پشتیبانی را انجام میدهند.
تهیه منشور پروژه:
قدم بعدی پس از گردآوری تیم، تهیه ی منشور پروژه است . منشور پروژه، مبنای پروژهی BPM است که شامل موارد زیر است:
مفهوم منشور پروژه در BPM بسیار مشابه این مفهوم در متدولوژی شش سیگما است.
در بخش مشکلات فرآیندی، وضعیت (یا کمبودها) فرآیندهای جاری و چالشهای کسب و کار مستند میگردد.
محدودهی پروژه، به محدوده ای که واحد اجرایی فرآیند برای انجام پروژه نیازمند است، اطلاق میشود.
برای دستیابی به اهداف اجرایی پروژه نیازمند این هستیم که تیمهای متنوعی انتظارات خود را بصورت کلی از پروژه بیان کنند. این اهداف بصورت کلی بوده و در فاز طراحی به جزئیات بیان خواهند شد، ولی در این مرحله تمامیانتظارات بدست آمده باید در منشور پروژه بیان شوند. در انتها تمامینقشها و مسئولیتهای درگیر در پروژه (که از تیمهای ذینفعان، کاربران کسب و کار و کمیته ی راهبری پروژه دریافت شده است) و زمانبندی مرتبط با آنها در منشور پروژه ثبت میگردد. زمانبندی که در منشور پروژه مطرح میگردد یک زمانبندی کلی است که بر اساس تجربههای پیشین انتخاب شده و در فاز طراحی مورد بازبینی قرار میگیرد.
هدف اصلی از تهیه ی منشور پروژه، برقرای ارتباط مابین تمامیبخشهای درگیر در پروژه است. منشور پروژه به امضاء کمیتهی راهبری و ذینفعان پروژه میرسد. پس از تایید منشور پروژه، اعضاء میتوانند از آن به عنوان یک حکم برای رسمیت شناختن ماهیت پروژه و اقدامات مرتبطشان استفاده کنند.
تجزیه و تحلیل فرآیندها:
لازم است که در حین آماده سازی منشور پروژه، تیم پروژه تجزیه و تحلیل فرآیندهای جاری سازمان را انجام دهد. قسمتی از این اطلاعات بصورت کلان در فاز جستجو جمع آوری شده است ولی در مرحله ی تجزیه و تحلیل، این اطلاعات با هدف دستیابی به میزان کارایی فرآیندهای موجود به تفصیل شرح داده میشود. دست یابی به دادههای فرآیندهای در حال اجرا کار ساده ای نیست زیرا ممکن است داده ی قابل استناد وجود نداشته باشد یا اینکه به راحتی نتوان به آن دست یافت.
اگر در یک فرآیند، سیستمهایی از قبل وجود دارند که وقایع را ثبت میکنند، از این وقایع ثبت شده میتوان برای ارزیابی مدت زمان فعالیتها استفاده کرد. برخی اوقات که ثبت وقایع سیستمی وجود ندارد میتوان با استفاده از اندازه گیری غیر مستقیم، میانگین مدت زمان فعالیتها را بدست آورد، بدین ترتیب که مدت زمان انجام کلیه تراکنشها را بر تعداد تراکنشهای انجام شده در آن دوره ی زمانی تقسیم کنیم.
تکنیکهای دیگر برای اندازه گیری فرآیندها، شامل مشاهدهی حضوری و انجام مصاحبه با کارکنان است. واحد اجرایی فرآیند وظیفه دارد ابزارها و تکنیکهای تجزیه و تحلیل فرآیندهای جاری را تعبیه کند. در حین اندازه گیری کارایی فرآیندهای جاری توسط تیم پروژه چالشهای فرآیند نیز باید مشخص شود تا با استفاده از هر دوی آنها، اهداف واقع بینانه ی پروژه قابل ترسیم باشد. نتیجهی این تجزیه و تحلیل به عنوان یکی از موارد منشور پروژه مطرح میگردد.
ادامه در متدولوژی عملیاتی BPM – قسمت پنجم
ترجمه و گردآوری: تیم مدیریت محتوای رایورز
سوالی دارید از ما بپرسید
تلفن: 89326444-021
آنچه در این مقاله میخوانید