چند نکته در حاشیه‌ی پست “مدل فرایندی APQC PCF در میدان عمل”

پستی که در مورد مدل فرایندی APQC PCF و نتایج بررسی وضعیت کاربرد آن‌ها در عمل نوشته بودم، بازتاب خوبی پیدا کرد و کامنت‌های بسیار خوبی توسط دوستان در مورد آن داده شد. به نظرم رسید بد نیست چند نکته اضافی‌تر را در این مورد مرور کنیم:

۱. شاید به‌تر بود من اول در مورد این‌که مدل مرجع فرایندی چیست و به چه دردی می‌خورد می‌نوشتم و بعد درباره‌ی مدل‌های مرجع موجود در ادبیات مدیریت. در این مورد حتما در آینده خواهم نوشت؛ اما فعلا همین را داشته باشید که یک مدل مرجع قرار نیست عینا در جایی که از آن استفاده می‌شود پیاده‌سازی شود. استفاده از هر مدل مرجعی، حتما نیازمند سفارشی‌سازی است. این‌که سفارشی‌سازی چیست و چگونه باید انجام شود، بحثی است که بعدتر به آن هم خواهیم رسید.

۲. خوبی مدل APQC PCF این است که در قالب یک مدل جامع، کلیه‌ی فرایندهای سازمان را جمع‌آوری کرده و از آن به‌تر این‌که هر کارکرد (Function) در این مدل، یک پکیج جداگانه است و می‌توانید برای معماری فرایندی هر بخش از سازمان از این بخش‌ها به صورت جداگانه هم استفاده کنید.

۳. یک نکته را فراموش نکنید: در جایی که مدل خاص فرایندی یک صنعت خاص وجود دارد، APQC PCF خیلی شاید کاربردی نباشد و به‌تر است در چنین صنایعی در بخش فرایندهای اصلی از مدل خاص آن صنعت بهره برد و برای فرایندهای بخش پشتیبانی  سازمان به سراغ مدل APQC PCF رفت. از این مدل‌های خاص هم زیاد داریم؛ چند تا مثال‌اش را آقای محمد حسین در کامنت‌‌های‌شان در پست قبلی اشاره کرده‌اند. از جمله: مدل eTOM که خاص صنایع مخابراتی است یا مدل‌های COBIT و ITIL که فرایندهای خاص مدیریت فناوری اطلاعات را در سازمان به دست می‌دهند. یک مدل خاص بسیار مهم دیگر هم مدل SCOR است که خاص مدیریت زنجیره‌ی تأمین است.

۴. هر جایی که فرایند معنادار باشد، مدل مرجع فرایندی هم معنادار است. بنابراین انجام پروژه‌ها هم می‌تواند مدل مرجع فرایندی داشته باشد. از این دیدگاه است که مثلا مدل PMBOK هم یک مدل مرجع فرایندی برای فرایندهای مدیریت پروژه است و RUP هم مدل مرجع مدیریت پروژه‌های توسعه‌ی نرم‌افزار است.

۵. اما حواس‌مان باشد که مدل مرجع (Reference Model) با چارچوب (Framework) فرق دارد. چارچوب از اسم‌اش معلوم است که چیست: مجموعه‌ای از قواعد و تعاریف که به نشان می‌دهند که مسئله‌ی مورد نظر چه اجزایی دارد، ارتباط میان آن اجزا چیست و چطور باید در مورد حل آن فکر کنیم. از همین تعریف مختصر مشخص است که چارچوب چیزی فراتر از متدولوژی و مدل مرجع است. بطور خلاصه: برای حل یک مسئله می‌توان چارچوب‌های مختلفی داشت و هر چارچوب هم می‌تواند شامل چندین متدولوژی و مدل مرجع باشد. براساس توضیحات فوق لازم است توجه کنیم که در موردِ خاص معماری سازمانی، آن چیزی که ما می‌شناسیم و به‌کار می‌گیریم از جنس چارچوب است (مثل: TOGAF، FEAF، EAP و …) و نه مدل مرجع فرایندی. البته چارچوب معماری دولت فدرال آمریکا (FEAF) یک مزیت دارد و آن‌ هم این‌که برای لایه‌های مختلف معماری دارای مدل‌های مرجع جداگانه است. مدل مرجع فرایندی این چارچوب، مدل BRM یا (Business Reference Model) است که فرایندها را در سطح سرویس‌های حاکمیتی تعریف کرده است (و به همین دلیل است که به درد معماری سازمانی در سطح دولت / حاکمیت می‌خورد و نه سطح سازمان‌های خصوصی.) بنابراین آقای محمد حسین عزیز باید به این نکته توجه کنند که ما برای این مجبوریم در لایه‌ی معماری کسب و کار پروژه‌های معماری سازمانی سراغ مدل‌هایی مثل APQC PCF، eTOM یا SCOR برویم که چارچوب‌های معماری سازمانی مدل مرجع فرایندی به همراه خود ندارند.

۶. در بعضی حوزه‌ها عملا Best Practiceهای فرایندها در قالب نرم‌افزارهای موجود در بازار (که حتی به شکل اوپن سورس هم در دسترس هستند) شکل مدل مرجع را به خود گرفته‌اند؛ از جمله مثلا فرایندهایی که با CRMها در سازمان‌ها پیاده‌‌سازی می‌شوند. البته علت اصلی این است که این نرم‌افزارها حوزه‌ی فعالیتی را به سازمان اضافه می‌کنند که قبلا وجود نداشته و البته اساسا بدون بهره‌گیری از IT هم قابل اجرا نیست (این نکته هم باز در مورد کامنت آقای محمد حسین.)

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

پ.ن. من در زمینه‌ی سفارشی‌سازی، به‌کارگیری و طراحی فرایندهای سازمان براساس مدل APQC PCF تجارب مفیدی داشته‌ام (رزومه‌ی من)‌ و بر این اساس برای ارائه‌ی خدمات مشاوره و آموزش به سازمان‌ها در زمینه‌ی بهبود و بازطراحی و بازمهندسی فرایندهای کسب و کار براساس مدل مرجع APQC PCF و سایر مدل‌های مرجع آمادگی دارم. در صورت تمایل می‌توانید برای دریافت کاتالوگ خدمات مشاوره و آموزش در این زمینه یا طرح سؤالات فنی خود با من تماس بگیرید.

به‌زودی بسته‌ی کاملی از مستندات و فایل‌های راهنمای مربوط به مهندسی فرایندها ـ به‌ویژه در حوزه‌ی مدل APQC PCF ـ (شامل: کتاب، راهنماها، فرم‌ها و تمپلیت‌های مربوط به فازهای مختلف مهندسی فرایندها، نمونه‌های بهترین فرایندها و …) برای استفاده آماده خواهد شد. برای اطلاع یافتن از عرضه‌ی این بسته جهت خریداری آن لطفا ایمیل‌تان را این‌جا ثبت فرمایید.

دوست داشتم!
۱۱

۴ thoughts on “چند نکته در حاشیه‌ی پست “مدل فرایندی APQC PCF در میدان عمل”

  1. از این بازتاب مفصل و اهمیتی که به نظرهای من دادید و لطفی که داشتید متشکرم. فقط در مورد نکته‌ی ۵ شما، من کاملاً متوجه چیزی که گفتید هستم. همان‌طور که گفتید چارچوب‌های معماری سازمانی [علاوه بر بخش‌های دیگر] می‌توانند شامل متدولوژی‌ها و همچنین مدل‌های مرجع (فرایندی و غیرفرایندی) باشند. TOGAF مدل مرجع فرایندی ندارد اما یک متدولوژی یا فرایند (به نام ADM) برای انجام معماری سازمانی ارائه می‌دهد. بنابراین فکر می‌کنم آوردن آن بین مدل‌های مرجع فرایندی در پیمایش مربوطه کار جالبی نبود، چون فقط فرایند یک محدوده‌ی خاص (معماری سازمانی) را پوشش می‌دهد در حالی که سایر مدل‌های مرجع یا کل سازمان را پوشش می‌دادند یا بخش بزرگی از سازمان را (مثل ITIL که فناوری اطلاعات را پوشش می‌دهد).
    یعنی TOGAF را نباید می‌آوردند اما حالا که آورده‌اند احتمالاً منظورشان فرایند معماری سازمانی TOGAF بوده چون TOGAF فرایند (یا مدل مرجع فرایندی) دیگری ندارد.

    در مورد فنی‌نویسی هم طبیعتاً برای داشتن مخاطب بیشتر حق شماست. اما کاش وب‌نوشتی بود که می‌شد در مورد این مسائل فنی‌تر در آن با آدم‌های باسواد بحث کرد! وب‌نوشت آقای جلالی‌نیا هست، منتها ایشون دیر به دیر به‌روز می‌کنند و زیاد هم به نظرها جواب نمی‌دهند.

Leave a Reply

Your email address will not be published.Required fields are marked *