در قسمت سوم این مطلب، فاز دوم متدولوژی عملیاتی BPM ارائه گردید. در ادامه، فاز ۳ یعنی تجزیه و تحلیل (Analyze) ارائه می‌شود.
فاز ۳: تجزیه و تحلیل (Analyze)
چهار فاز بعدی، بیانگر نمای کلی پروژه BPM است. هر پروژه BPM، شامل این چهار فاز می‌باشد. هر بار که پروژه‌ای کامل می‌شود (طراحی و اجرای یک فرآیند، کامل می‌شود)، تیم اجرای فرآیند می‌تواند فرآیند جدیدی را آغاز نموده و این چهار فاز را دوباره طی نماید.
این فاز شامل برنامه‌ریزی پروژه و تجزیه و تحلیل فرآیند می‌شود. ورودی این فاز، لیست فرآیندهایی است که توسط واحد اجرای فرآیند برای پیاده‌سازی انتخاب شده‌اند و زمان لازم برای پیاده‌سازی آن نیز تخمین زده شده است.
در این فاز تیم پروژه باید منشور پروژه را تهیه و فرآیندهای موجود را با در نظر گرفتن محدوده پروژه تجزیه‌وتحلیل کنند.
ما در این بخش به نحوه برپایی تیم پروژه، منشور پروژه و تجزیه‌وتحلیل فرآیند می‌پردازیم. موارد زیر، خلاصه کلیه وظایفی که در این فاز مطرح می‌شود را بیان می‌کند:
جمع‌آوری تیم پروژه:
-رهبران تغییر و اعضاء اصلی تیم در پروژه مستقر شوند
-کمیته راهبری پروژه تشکیل گردد
-درگیر کردن ذینفعان پروژه
تهیه منشور پروژه:
-مشکلات فرآیند، محدوده پروژه، اهداف پروژه، نقش‌ها و مسئولین، برنامه‌ریزی کلان پروژه و مفروضات پروژه مشخص شوند
-تأییدیه منشور پروژه از کمیته راهبری و ذینفعان پروژه دریافت گردد
انجام تجزیه‌وتحلیل فرآیندها:
-داده‌های فرآیندی موجود در محدوده پروژه دریافت گردد
-برای دستیابی به میزان کارایی فرآیندهای موجود، داده‌های دریافت شده تجریه‌وتحلیل گردد
-چالش‌های فرآیندهای جاری مستند شوند
در ادامه به تشریح هر یک از موارد بالا می‌پردازیم.
جمع آوری تیم پروژه
یک تیم پروژه باید حداقل شامل اعضاء زیر باشد:
-مدیر پروژه
-مسئول تغییرات کسب‌وکار
-توسعه‌دهنده و تیم پشتیبان تکنولوژی
تصویر زیر، تیم های درگیر در پروژه را نمایش می دهد:
مسئولیت تمامی دستاوردها و شکست‌ها با مدیر پروژه است. بهترین حالت، زمانی است که تنها یک مدیر پروژه وجود داشته باشد تا در انتها یک شخص، پاسخ‌گو باشد. مسئولیت‌های مدیر پروژه شامل موارد زیر است:
-تهیه برنامه پروژه
-هماهنگی تیم‌های درگیر در پروژه
-کسب مشارکت از ذینفعان
-همراه ساختن کمیته راهبری پروژه
تمامی افرادی که تحت تأثیر اجرای پروژه قرار می‌گیرند، ذی‌نفع پروژه محسوب می‌گردند. ذی‌نفع می‌تواند مدیر یک واحد باشد (به علت درگیری در پروژه BPM)، واحد فناوری اطلاعات (زیرا وظیفه پشتیبانی از سیستم را به عهده دارد)، و یا کاربران باشند (زیرا برای انجام روش جدید کارشان نیاز به آموزش دارند).
کمیته ذینفعان از مدیران ارشد هر واحد کسب‌وکار تشکیل شده که برای این پروژه، گرد هم آمدهاند.
تیم تغییرات کسب‌وکار، مسئولیت هدایت طراحی فرآیندهای کسب‌وکار و نیز محورسازی سازمان را برعهده دارند.
این تیم باید شامل رهبران تغییر، اعضاء اصلی تیم، کارشناسان طراحی چارت و کارشناسان طراحی فرآیند باشد. رهبران تغییر باید تیم تغییرات کسب‌وکار را رهبری کرده و همچنین واحدهایی را که تحت تأثیر تغییرات قرار گرفته اند را با شرایط جدید وفق دهند.
اعضاء اصلی تیم، شامل نمایندگانی از واحدهای کسب‌وکارند که با نحوه اجرای فرآیندهای جاری به خوبی آشنا هستند.
این افراد باید مورد احترام و اعتماد واحد سازمانی خود باشند و همچنین در ماهیت پروژه شک و تردیدی نداشته باشند تا بتوانند ارتباطی قوی -در رابطه با پروژه- با باقی افراد سازمان برقرار کنند؛ در غیر این صورت، بازخورد منفی به وجود خواهد آمد.
سؤالی که مطرح می‌شود: تفاوت رهبران تغییر با اعضاء اصلی تیم در چیست؟ اعضاء اصلی تیم از لحاظ موقعیت سازمانی به بطن کار بسیار نزدیکند، آنها درک خوبی از چگونگی نحوه اجرای فرآیندهای بخش خود دارند.
در صورتی که رهبران تغییر به طور معمول رده بالاتری در چارت سازمانی دارند و علاوه بر رهبری تغییرات کسب‌وکار، با مدیران سطوح میانی و بالاتر در تعامل هستند.
دیگر اعضاء تیم تغییر شامل کارشناسان طراحی فرآیند و چارت سازمانی هستند. کارشناسان طراحی چارت سازمانی وظیفه دارند تا چارت سازمانی را از جنبه عملکرد بهینه فرآیندها مورد تجزیه‌وتحلیل قرار دهند.
این امر گاهی اوقات ممکن است به تغییرات در چارت سازمانی منتهی شود که در نهایت تغییر نقش‌ها و شغل‌های افراد را به دنبال دارد.
کارشناسان طراحی چارت سازمانی می‌بایست نقش‌ها و مسئولیت‌های شغل‌های به وجود آمده را مشخص نموده و علاوه بر این، اهداف فرآیندها و پاداش دستیابی به این اهداف را نیز باید مشخص کنند.
در این حین، کارشناسان طراحی فرآیند به تجزیه‌وتحلیل فرآیندهای کسب‌وکار جاری پرداخته و مطابق اصول BPM، آنها را بازطراحی می‌کنند.
کارشناسان طراحی فرآیندها -در حین متدولوژی BPM - طراحی و شبیه‌سازی فرآیند (با ابزار BPMS) را آموزش می‌بینند.
در واقع، مسئولیت اصلی تیم طراحی این است که سناریوهای فرآیندی را از سایر تیم‌های پروژه دریافت و مطابق تکنیکهای طراحی فرآیند، مناسب‌ترین فرآیند در حوزه پروژه را طراحی کنند (برای کسب اطلاعات بیشتر در مورد تکنیکهای طراحی فرآیند، می توانید از این منبع استفاده کنید).
پشتوانه تیم تغییر، تیم‌های توسعه و پشتیبانی تکنولوژی هستند. تیم توسعه شامل برنامه‌نویس‌هایی است که طراحی فرآیندهای کسب‌وکار را پشتیبانی می‌کنند.
شرکت‌های ارائه‌دهنده BPMS در تبلیغات ادعا می‌کنند که "محصولشان به صورت خودکار کدنویسی انجام می‌دهد". بر این اساس، برخی از شرکت‌ها تا آنجا پیش می‌روند که محصول خود را "راهکار بدون نیاز به کدنویسی" معرفی می‌کنند.
در حقیقت کدنویسی برای تمامی ابزارهای BPMS لازم است، مگر اینکه فرآیند را به فرم‌های ساده، واسط میانی، رابط کاربری ساده و بهره‌گیری از ماژول‌های آماده محدود کنیم.
همچنین برای پیاده‌سازی‌های پیچیده مانند قوانین، واسط‌های کاربری و تغییرات در ماژول‌ها، نیازمند توسعه‌دهنده هستیم.
تیم توسعه باید شامل: طراح وب، توسعه‌دهنده وب، معمار برنامه کاربردی سازمان، توسعه‌دهندگانی که کار با ابزار BPMS را آموزش دیده‌اند و توسعه‌دهندگان سیستم‌های پیشین (که در این پروژه مطرح می‌شوند) سازمان باشند. البته با وجود این سمت‌ها در تیم ممکن است توسعه‌دهندگانی باشند که بتوانند چندین سمت را به عهده گیرند و تعداد افراد، کمتر از تعداد سمت‌ها باشد.
تفاوت مشهودی میان توسعه‌دهنده و طراح‌وب است. طراح‌وب، ظاهر وب‌سایت را آماده می‌سازد؛ در‌حالی‌که توسعه‌دهنده با برنامه‌نویسی سمت سرور، وب‌سایت را کنترل می‌کند.
معمار برنامه کاربردی، مدل ماژول‌های موجود در حوزه پروژه را تهیه می‌کند. اطمینان از امکان استفاده مجدد از برنامه‌های کاربردی قبلی- که در حوزه پروژه هستند - و نظارت بر برنامه‌های کاربردی -که در آینده طراحی خواهند شد- از وظایف معمار برنامه‌های کاربردی می‌باشد.
وظیفه دیگر او، کسب اطمینان از رعایت استانداردهای پروژه BPM توسط برنامه‌های کاربردی سازمان است؛ چرا که اکثر برنامه‌های کاربردی در سازمان‌ها از واسط‌های مناسبی برای برقراری ارتباط با BPMSها برخوردار نیستند. بنابراین توسعه‌دهندگانی که با این سیستم‌های سازمانی آشنایی دارند باید در تیم توسعه پروژه همکاری داشته باشند تا از برقراری ارتباط میان این سیستم‌ها با ابزار BPMS اطمینان حاصل گردد.
آخرین تیم در پروژه، تیم پشتیبان تکنولوژی است. این تیم، وظایف مدیر سیستم و بهینه‌سازی عملکرد سیستم را بر عهده دارد که برای دستیابی به موفقیت در پروژه‌های بزرگ، وجود یک تیم اختصاصی پشتیبانی الزامی است.
تأخیر در زمانبندی چنین پروژه‌هایی، می‌تواند به ضررهای مالی بزرگی منجر شود. اعضاء تیم پشتیبان تکنولوژی این تضمین را می‌دهند که عامل تأخیر در پروژه، مربوط به تکنولوژی نباشد. جدای از اندازه پروژه، آنها برای زمان پاسخ‌گویی خدمات با دیگر تیم‌های پروژه به توافق می‌رسند و بر اساس این موافقت‌نامه سطح خدمت (SLA)، در فازهای حساس پروژه، مناسب‌ترین پشتیبانی را ارائه می‌دهند.
تهیه منشور پروژه
گام بعدی پس از گردآوری تیم، تهیه منشور پروژه است (می‌توانید نمونه‌ای از منشور پروژه را از اینجا دانلود کنید). منشور پروژه، مبنای پروژه BPM بوده که شامل موارد زیر است:
-مشکلات فرآیندی
-محدوده پروژه
-اهداف اجرایی پروژه
-نقش‌ها و مسئولیت‌ها
-برنامه‌ریزی کلان
-فرضیات پروژه
مفهوم منشور پروژه در BPM بسیار مشابه این مفهوم در متدولوژی شش سیگما است.
در بخش مشکلات فرآیندی، وضعیت (یا کمبودها) فرآیندهای جاری و چالش‌های کسب‌وکار مستند می‌گردد.
در بخش محدوده پروژه، به محدوده‌ای که واحد اجرایی فرآیند برای انجام پروژه نیازمند است، اطلاق می‌شود.
برای دستیابی به اهداف اجرایی پروژه، نیازم داریم که تیم‌های متنوعی انتظارات خود را به صورت کلی از پروژه بیان کنند.
این اهداف به صورت کلی بوده و در فاز طراحی با جزئیات، بیان خواهند شد؛ لیکن در این مرحله تمامی انتظارات به دست آمده باید در منشور پروژه بیان شوند. در انتها تمامی نقش‌ها و مسئولیت‌های درگیر در پروژه (که از تیم‌های ذینفعان، کاربران کسب‌وکار و کمیته راهبری پروژه دریافت شده است) و زمانبندی مرتبط با ایشان در منشور پروژه ثبت می‌گردد. زمانبندی که در منشور پروژه مطرح می‌گردد، کلی است که بر اساس تجربه‌های پیشین انتخاب شده و در فاز طراحی مورد بازبینی قرار می‌گیرد.
هدف اصلی از تهیه منشور پروژه، برقرای ارتباط مابین تمامی بخش‌های درگیر در پروژه است. منشور پروژه به امضاء کمیته راهبری و ذینفعان پروژه می‌رسد. پس از تأیید منشور پروژه، اعضاء می‌توانند از آن به عنوان حکمی برای به رسمیت شناختن ماهیت پروژه و اقدامات مرتبتشان استفاده کنند.
تجزیه و تحلیل فرآیندها
لازم است که در حین آماده‌سازی منشور پروژه، تیم پروژه تجزیه‌وتحلیل فرآیندهای جاری سازمان را انجام دهد.
بخشی از این اطلاعات -به صورت کلان- در فاز جستجو جمع آوری شده است، لیکن در مرحله تجزیه‌وتحلیل، این اطلاعات با هدف دستیابی به میزان کارایی فرآیندهای موجود به تفصیل شرح داده می‌شود.
دستیابی به داده‌های فرآیندهای در حال اجرا، کار ساده ای نیست. زیرا ممکن است داده قابل استنادی، وجود نداشته باشد یا به راحتی نتوان بدان دست یافت.
چنانچه در فرآیندی، سیستم‌هایی از پیش وجود دارند که وقایع را ثبت می‌کنند، از آنها می‌توان جهت ارزیابی مدت زمان فعالیت‌ها استفاده نمود.
برخی اوقات که ثبت وقایع سیستماتیک نیست، می‌توان با کمک اندازه‌گیری غیرمستقیم، میانگین مدت زمان فعالیت‌ها را به دست آورد؛ بدین ترتیب که مدت زمان انجام کلیه تراکنش‌ها را بر تعداد تراکنش‌های انجام شده در آن دوره زمانی تقسیم نمود.
تکنیک های دیگر برای اندازه گیری فرآیندها شامل مشاهده حضوری و انجام مصاحبه با کارکنان است. واحد اجرایی فرآیند، وظیفه دارد ابزارها و تکنیکهای تجزیه‌وتحلیل فرآیندهای جاری را تعبیه کند.
در حین اندازه‌گیری کارایی فرآیندهای جاری -توسط تیم پروژه- چالش‌های فرآیند نیز باید مشخص شود تا با استفاده از هر دوی آنها، اهداف واقع‌بینانه پروژه قابل ترسیم باشد. نتیجه این تجزیه‌وتحلیل به عنوان یکی از موارد منشور پروژه مطرح می‌گردد.
منبع: پایگاه دانش BPM رایورز 
دریافت لینک صفحه با کد QR