در سال 1985 هنگامیكه مایكل پورتر برای اولین بار زنجیره ارزش را تعریف كرد، فرآیندهای تشكیل دهنده زنجیره ارزش را به دو گروه تقسیم نمود:
1. فرآیندهای اصلی  (Core Processes) كه برای محصول یا خدمات تولید شده سازمان ارزش افزوده ایجاد می كنند
2. فرآیندهای پشتیبان كه برای توانمند سازی فرآیندهای اصلی ضروری هستند

 در اوایل دهه نود، این تقسیم‌بندی در میان آن‌هایی كه درگیر بازمهندسی (Reengineering) فرآیندهای كسب و كار (BPR) شدند، عمومیت یافت. در همین زمان، یك نظریه دیگر مطرح شد كه بر روی دسته سوم از فرآیندها تمركز می كرد، این دسته سوم فرآیندهای مدیریت بودند. راملر و براچه(Rummler and Brache)، برای مثال، بیان كرده‌اند كه هر تیم بازمهندسی باید همواره هم به فرآیندی كه بازطراحی می‌شود و هم به مدیریت فرآیند توجه كنند. اندكی بعد، موسسه مهندسی نرم افزار (Software Engineering Institute) بر روی نیاز برای تغییر فرآیندهای مدیریت برای حركت به سطح بعدی از مدل بلوغ توانمندی CMM تمركز كرد. و بعدها در دهه نود، هنگامیكه انجمن مربوط به زنجیره تامین مدل SCOR را ارائه دارد، فرآیندها را تحت سه گروه فرآیندهای اصلی، فرآیندهای توانمندساز و فرآیندهای برنامه‌ریزی در جهان توصیف كرد. امروزه اكثر تحلیل گران بین فرآیندهای اصلی، پشتیبان و مدیریتی این تمایز را قائل می‌شوند. 
 
متأسفانه برای اغلب افراد خیلی واضح نیست كه یك فرآیند مدیریت چگونه تشكیل می‌شود و این موضوع برای سازمان‌هایی كه تلاش می‌كنند معماری فرآیند كسب و كارشان را تعریف كنند، موجب افزایش اشتباهات می‌شود. این موضوع هنگامی پیچیده‌تر می‌شود كه سازمان‌ها یك پروژه تغییر فرآیند را آغاز می‌كنند و می‌خواهند بدانند كه تیم بازطراحی باید به راهی كه مدیریت فرآیند كارش را انجام می دهند نیز وارد شوند یا نه. دراینجا موضوع با یك مثال از یك پروژه بازطراحی فرآیند آغاز می‌شود. شكل 1 یك فرآیند كسب و كار ساده زنجیره تحویل پیتزا را كه نیاز به بهبود دارد نشان می‌دهد.

 

یك تمایل ذاتی در میان تحلیل‌گران فرآیند وجود دارد كه یك فرآیند را بیازمایند تا ببینند كه كاركنان در آن چه كاری را انجام می‌دهند. هر كسی كه مقالات راملر را خوانده باشد، می‌فهمد كه مشكلاتی كه سازمان تجربه می كند اغلب ریشه در مدیریت یا نظارت فعالیت دارد تا در خود فعالیت‌ها.

 

شكل 2 یك مدل مدیریت فرآیند بسیار ساده را نشان می‌دهد.

 

 

لزوماً هر فرآیند یا فعالیت مشخص بوسیله فردی مدیریت می‌شود. اگر فرآیندها یا فعالیت‌هایی بدون مدیر باشند، سازمان مشكلات بزرگ‌تری نسبت به آن‌هایی كه در حال حاضر داریم خواهد داشت. فرد ممكن است به عنوان مدیر فرآیند نامیده شود یا نشود. در این مثال اغلب، او به عنوان "ناظر تهیه غذا" یا "ناظر تحویل" كار می‌كند و به یك واحد عملیاتی سنتی گزارش می‌دهد. اما یك نكته باقی می‌ماند، فردی مسئول تعریف كاری است كه انجام می‌شود هنگامیكه یك فرآیند اجرا می شود. او بودجه را توسعه می دهد، كار را مدیریت می‌كند، معیارها و خروجی‌ها را چك می‌كند، استخدام می‌كند، پاداش می‌دهد، ارتقا می‌دهد و یا كاركنان را اخراج می‌كند.
 
برای اینكه این نكته را دریابیم، در گروه Bptrend یك نمودار فرآیند رسم می‌شود كه فرآیند مدیریت را برای هر زیرفرایند در فرآیند نشان می‌دهد كه در شكل 3 نمایش داده شده است. SCOR چیزی بسیار شبیه به آن دارد و نیاز دارد كه تحلیل‌گر یك فرآیند برنامه‌ریزی برای فرآیندهای اصلی در دیاگرام SCOR نشان دهد

 

 

اگر به شكل ساده بر روی بازطراحی و بهبود فرآیندها تمركز شود به نظر نمی‌رسد كه دربر گرفتن فرآیندهای مدیریتی قابل صرف وقت باشد. ساده تر است كه بگوییم فرآیند پیتزا شامل یك فعالیت آماده‌سازی غذا است و بخش مربوط به تحلیل فعالیت كه باید بر روی چگونگی مدیریت آن تمركز شود.
 

مشكلات هنگامی بر می‌آید كه كار بر روی معماری فرآیند كسب و كار با ابعاد بزرگ آغاز می‌شود. چگونه فرآیندهای درون گروه استراتژی یا فعالیت‌های مركز تعالی سازمان یا فرآیندها وابسته به برنامه‌ریزی سازمانی طبقه‌بندی می‌شوند؟ این فرآیندها معمولاً از فرآیندهای ویژه‌ای كه تحلیل می‌شوند، دور مانده‌اند اما آن‌ها مرتباً اثراتی را بر روی آن فرآیند مشخص می‌گذارند. تصور كنید برای مثال، كه سازمانی كه صاحب زنجیره پیتزا است یك سیاست دارد كه نتیجه‌اش قوانین كسب و كاری است كه مدیریت آن مغازه پیتزا فروشی باید اجرا كند. حالا همان پروژه بهبود فرآیند خودمان در زنجیره پیتزا فروشی را در نظر بگیرید كه سه یا چهار فعالیت غیرمؤثر را تشخیص داده است كه باید در نتیجه سیاست‌های سازمان مادر انجام شود. لذا دیاگرام ما ممكن است شبیه به شكل 4 شود:
 
 

 

مشخصا اگر ما یك معماری فرآیند كسب و كار را ایجاد كنیم، احتمالاً می‌خواهیم كه یك فرآیند سیاست گذاری را نشان بدهیم و ممكن است حتی یك فرآیند قانون‌گذاری كسب‌ و كار را نیز نشان دهیم، اما ما احتمالاً نمی‌خواهیم كه مدیریت فرآیند مدیریت تحویل را نشان دهیم. در واقع تنها فرآیندهای مدیریت اجرایی است كه تیم‌ها معمولاً می‌خواهند در در معماری فرآیند كسب و كار بگنجانند. 
 
از طرف دیگر، هنگامیكه شما لیستی از فرآیندهای مدیریت را كه با چارچوب‌هایی از جمله SCOR، VCOR یا با COBIT و CMMI كار می‌كنند را نگاه كنید، پی خواهید برد كه آن‌ها فعالیت‌های مدیریت در هم تنیده شده‌ای هستند كه بخشی از فرآیند مدیریت هر روزه هستند، همراه با فرآیندهای مدیریت مستقل بنگاه. در همان زمان، اغلب شركت‌ها بر روی این واقعیت كه این چارچوب‌های فرآیند كسب و كار اغلب فرآیندهای مدیریت را تعریف می‌كنند، تمركز نمی‌كنند. بنابراین، هر سازمانی كه SCOR، cobit، CMMI را به كار می‌برد احتمالاً بدون تفكر در باره آن، آن‌را انطباق داده است. سه رویه مختلف  هر یك با تعاریف خودشان و هر یك بنا به ضرورت‌های مربوط به خودشان برخی فعالیت‌های مدیریت فرآیند كلیدی را تعریف نموده‌اند. اگر آن‌ها در چارچوب مربوط به مؤسسه مدیریت پروژه استفاده شوند ، آنگاه آن‌ها یك مجموعه چهارمی از فرآیندها و تعاریف را خواهند داشت. سازمان‌ها در باره انطباق دو چارچوب زنجیره تأمین مختلف فكر می‌كنند و آن‌را اجرا نمی‌نمایند اما معمولاً در همان زمان درباره چگونگی انطباق چارچوب‌هایی كه تعاریف متفاوتی از فرآیند مدیریت فرآیند را ارائه میدهند نگرانی ندارند. 
 
نكته آنجاست كه همه نیازمندیم كه بیشتر درباره فرآیندهای مدیریت فكر كنیم تا در خصوص تعریف بهینه یك فرآیند مدیریت، به یك اتفاق نظر دست یابیم.