ايتنا - متدولوژی عملیاتی BPM

در قسمت چهارم این مطلب، فاز سوم متدولوژی عملیاتی BPM ارائه گردید. در ادامه، فاز ۴ یعنی طراحی (Design) ارائه می‌شود.

فاز ۴: طراحی (Design)
زمانی که به فاز طراحی می‌رسیم، پروژه بسیار سریع در حال انجام است. هدف اصلی فاز طراحی، دستیابی به بهترین راهکار مدیریت فرآیند و ساخت یک نمونه اولیه -برای اطمینان از امکان اجرایی بودن آن- است. موارد زیر، خلاصه کلیه وظایفی که در این فاز مطرح می‌گردد را بیان می کند:

بهینه‌سازی طراحی فرآیندهای کسب‌وکار
    -کارگاه‌های آموزشی برای دستیابی به سناریوهای فرآیندی برگزار گردد
    -پیش‌نویس فرآیند جایگزین تهیه گردد
    -برای دستیابی به بهترین فرآیند جایگزین، از شبیه‌ساز استفاده کنید
    -فرآیند جایگزین را با شبیه‌سازی و پالایش‌های مکرر، بهینه‌سازی کنید

ساخت نمونه اولیه (Prototype) فرآیند
   -بخش‌های اصلی فرآیند را انتخاب کنید
   -منطق کسب‌وکار، درگاه اتصال به مؤلفه‌ها و صفحات وب را در نمونه اولیه فرآیند، پیاده‌سازی کنید

تکمیل جزئیات راهکار
   -چارت سازمانی را بر اساس طراحی جدید، به‌روزرسانی کنید
   -جزئیات جریان فرآیند را طراحی کنید
   -مدل فنی راهکار فرآیند را پیاده‌سازی کنید
   -مستندات طراحی عملیاتی (Functional Design) را کامل کنید

تیم تغییر کسب و کار، مسئول طراحی فرآیند در این فاز است. برای دریافت سناریوی فرآیند و نظرات، جلسات و کارگاه‌های آموزشی با تمامی ذی‌نفعان کسب‌وکار برگزار می‌شود.
پس از دریافت نظرات ذی‌نفعان، تیم تغییر با کمک کارشناسان طراحی، به جمع‌بندی کلی از فرآیند طراحی شده، دست می‌یابد.
فرآیند طراحی شده با ابزار طراحی فرآیند BPMS و شبیه‌سازها اجرا می‌گردد تا مناسب‌ترین فرآیند، جایگزین گردد.
به عبارت ساده‌تر،فرآیندها همانند لایه‌های یک پیاز هستند که هنگام بررسی هر لایه جزئیات بیشتری مطرح می‌گردد.
بنابراین فرآیند انتخاب شده همانند دنیای واقعی در چرخه شبیه‌سازی و پالایش قرار می‌گیرد تا تمامی نقاط تصمیم‌گیری، مسیرهای فرآیندی و استثنائات آن مورد بازبینی قرار گیرد.
(علاقه‌مندان به مطالب بیشتر در رابطه با تکنیک‌های تحلیل و طراحی فرآیند می‌توانند کتاب‌های Harmon و Burlton در این زمینه را مطالعه کنند).
همزمان که طراحی فرآیندها مورد بازبینی قرار می‌گیرند، کارشناسان طراحی چارت سازمانی باید ساختار سازمانی را بر اساس این تغییرات به‌روزرسانی کنند.
این تغییرات می‌تواند هم‌چون تغییر عنوان یک شغل، ساده یا مانند ایجاد و حذف یک واحد سازمانی، بنیادی باشد. خروجی کار تیم تغییرات چارت سازمانی در این فاز شامل موارد زیر است:
   -شرح شغل‌ها
   -نقش‌ها
   -فعالیت‌ها
   -فرآیندهای کسب‌وکار

در انتهای این فاز، باید نقش‌های درگیر در فرآیندها و فعالیت‌های آتی (to-be) نهایی شده باشند.
برای مشخص شدن امکان پیاده‌سازی فرآیند آتی، باید یک نمونه اولیه از آن ساخته شود. نمونه اولیه باید شامل ویژگی‌های اصلی فرآیند باشد.
به عنوان مثال، اگر قرار باشد فرآیند با سایر برنامه‌های کاربردی سازمان یکپارچه شود، در نمونه اولیه حداقل یکی از این یکپارچگی‌ها پیاده‌سازی شود.
نمونه اولیه حاصل تلاش مشترک تیم‌های "تغییر کسب‌وکار" و "توسعه" است. در این میان، تیم توسعه این شانس را دارد که تا حدودی با فرآیند آشنا شود و میزان کدنویسی آن را پیش‌بینی کند. در حالی که در متدولوژی آبشاری، توسعه‌دهندگان پس از اتمام کار تیم اجرایی، می‌توانستند درگیر پروژه شوند.
ساخت نمونه اولیه فرآیند در فاز طراحی، علاوه بر نزدیک‌تر کردن روابط کاری دو تیم، به کاهش ریسک‌های پیاده‌سازی آن نیز منجر می‌گردد.
برخی اوقات تیم اجرایی، راهکارهایی عالی و زیبا -ولی بسیار پیچیده- را پیشنهاد می‌دهند که تنها تیم فنی می‌تواند امکان عملیاتی بودن/نبودن آن را در بازه زمانی پروژه تشخیص دهد. این امکان با وجود تیم فنی در این فاز مهیا می‌گردد تا پیاده‌سازی فرآیند از بُعد فنی نیز مورد بازبینی قرار گیرد.
معمار برنامه‌های کاربردی سازمان، برای ساخت نمونه اولیه فرآیند، یک مدل فنی سطح بالا طراحی می‌کند. مدل‌سازی او شامل یک مدل داده (Data Model) و یک مدل مؤلفه (Component Model) است.
در گذشته در متدولوژی شیء‌گرا برای ثبت تغییرات وضعیت شیء و جریان فعالیت‌های فرآیند از نمودارهای توالی (Sequence Diagram) و انتقال وضعیت (State transition) استفاده می‌شد؛ در صورتی که طبق رویکرد طراحی در BPMSها این دو نمودار به عنوان بخشی از طراحی فرآیند در ابزار -به صورت گرافیکی- مدل می‌شوند.
این امر مزیت یکپارچگی میان مدل‌سازی و توسعه را به همراه دارد؛ زیرا توسعه‌دهنده می‌تواند به سادگی منطق کدنویسی را به فرآیند مدل شده اضافه نموده و معمار برنامه‌های کاربردی سازمان نیز به جای صرف زمان روی طراحی نمودارهای برهم‌کنش (Interaction) تنها به طراحی توابع (Function) هر مؤلفه می‌پردازد.
نمودارهای برهم‌کنش و هم‌چنین جریان فرآیندها توسط کارشناسان طراحی فرآیند در ابزار BPMS مدل‌سازی می‌شوند.
معمار برنامه‌های کاربردی سازمان نیز برای پیشگیری از تناقض در طراحی مدل‌داده فرآیندها، آن را بر اساس مدل داده فعلی سازمان طراحی می‌کند. سایر اعضاء تیم فنی نیز به ساخت نمونه اولیه فرآیند می‌پردازند.
در صورتی که برای طراحی وب، مدلی از سمت سازمان پیشنهاد نشده باشد طراح وب می تواند با چند طراحی پیشنهادی انتخاب را به عهده تیم پروژه بگذارد. برای اطمینان از طراحی و پیاده سازی تمامی ویژگی های در نظر گرفته شده نمونه اولیه، باید کارشناس طراحی فرآیند با تیم توسعه -در حین ساخت- همکاری داشته باشد.
یکی از مشکلات اساسی متدولوژی‌های توسعه برنامه کاربردی، قطع ارتباط میان طراحی عملیاتی و خروجی کار توسعه‌دهنده است.
در این متدولوژی‌ها ابتدا تیم طراحی عملیاتی، نیازمندی‌های کسب‌وکار را جمع‌آوری کرده و بر اساس آنها مستندات طراحی عملیاتی تهیه می‌شود.
تیم تحلیلگر فنی این مستندات را به خصوصیات فنی تبدیل می‌کند که قابل درک و پیاده‌سازی توسط برنامه‌نویسان است.
چند لایه بودن ارتباطات و ترجمه‌های انجام شده در بین آنها موجب می‌گردد که معمولاً بین نیازمندی‌های اصلی و راهکار پیاده شده، اختلافاتی وجود داشته باشد.
متدولوژی BPM و بهره‌گیری از ابزار BPMS فاصله بین نیازمندی‌ها و توسعه‌دهندگان را کمتر می‌سازد.
ماژول طراحی فرآیند BPMS هر دو لایه جریان فرآیندها و منطق برنامه‌نویسی آنها را پوشش می‌دهد.

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

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

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

منبع: پایگاه دانش BPM رایورز

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