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


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

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

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

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

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

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

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

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

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

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


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

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

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

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد.