به سوی روش BPM سریع – نوشته پاول هارمون
بخش اول
مشکل روبروی سازمان ها
دنیا به سرعت در حال تغییر است و در آینده ی نزدیک حتی با سرعت بیش تری تغییر خواهد کرد. بنده تحقیقات فراوانی را روی هوش مصنوعی (AI) انجام داده ام. خبر خوب از زاویه ی دید یک متخصص فرآیند این است که بیشترین بخشAI خود را به صورت نوع دیگری از اتوماسیون ظاهر خواهد کرد. دقیقا همراستا با تلاش برای دیجیتالی تر نمودن سازمان هایمان، خواهیم دید که نیاز داریم سیستم های کاربردی AI را به فرآیندهای کسب وکاری موجود خود بیفزاییم. خبر بد این است که AI در نظر دارد تا افزایش گسترده ای در بازه ی چیزهایی که ما می توانیم به شکل اتوماتیک درآوریم ایجاد کند و دارد خودش را آماده می کند تا بازه ی گسترده ای از فناوری های بسیار مخرب را عرضه کند.
به عنوان مثال در عرض چند سال، قطعاً در خلال دهه ی آینده، ظهور فراگیر وسایل نقلیه ی خودکار را خواهیم دید. برخی از آنها کشتی های خودگردان مانند تانکرهای نفت خواهند بود. برخی از آنها کامیون های بین شهری و برخی دیگر خودرو خواهند بود. در برخی موارد خودروهای بدون راننده مغلوب هواپیماهای بدون سرنشینی خواهند شد که حتما محموله را به شکل بهتری به مقصد می رسانند. در همان زمان، وسایل نقلیه ی بدون سرنشین از حالت گازی به برقی تبدیل شده و شاید حتی به وسایل با سوخت هیدروژنی تبدیل گردند. یا مراکز خریدی را در نظر بگیرید که بیش تر در مناطق حومه ای در آمریکا دیده می شوند. انتظار داریم که حدود ۴۰ درصد از مغازه ها در آن مراکز خرید در دهه ی آینده یا چیزی نزدیک به آن، بسته شوند. زیرا در کشمکش شدیدشان با Amazon.com و سایر خرده فروشان اینترنتی مغلوب خواهند شد.
تقریبا همه ی ماشین آلات پیچیده به زودی به سیستم های خود-تشخیصی که واسط آن ها زبان طبیعی است، مجهز خواهند شد. آماده باشید که با دستگاه کپی خود وقتی که به مشکلی بر می خورد، گفتگویی را داشته باشید. به شیوه ای مشابه، انبارداری و فرآیندهای زنجیره ای تامینی جای خود را به پرینترهای سه بعدی ای خواهند داد که به جای واردات محموله و ذخیره سازی آن، به بخش های مورد نیاز را به هنگام تقاضا تولید خواهند کرد.
بنده می توانم ادامه دهم و تغییرات اساسی ای را که هم اکنون قابل پیش بینی هستند و در سال های آینده عملی خواهند شد، بشمارم. همین بس که بگویم هر شرکتی قرار است خودش را در طراحی مجدد و تغییرات مداوم ببیند.
تغییرات و عاملین فرآیند کسب و کار
عاملین فرآیندهای کسب و کار به شکل های مختلفی دیده می شوند، از تحلیل گران Lean and Six Sigma تا طراحان فرآیند، تحلیل گران کسب و کار و مهندسان باز طراحی فرآیند فناوری اطلاعات. بیش تر اینها یک وجه اشتراک دارند- آنها وابسته به روش هایی هستند که حداقل دو دهه و در بسیاری از موارد، حتی ۴ یا ۵ دهه پیش از این، توسعه یافته بودند. این روش ها، در بسیاری از موارد به خوبی در موردشان فکر شده است و به خوبی طراحی شده اند تا تحلیل جامع و کاملی از مشکلات کسب و کاری یک سازمان ارائه دهند. حتی امروزه نسخه های جدیدی از راهبرد های جامع در حال توسعه هستند-برای مثال کار معماری کسب و کار را که توسط بسیاری از افرادی انجام می شود که اصرار دارند که یک سازمان حتما معماری کسب وکار جامعی را برای کل سازمان داشته باشد، در نظر بگیرید.
مشکل روش های فرآیند جامع و کامل و معماری های جامع فرآیند کسب و کار این نیست که آنها اساسا اشتباه اند، اما مشکل شان این است که هیچ کس قرار نیست وقت کافی داشته باشد تا دهه های آینده آنها را به کار گیرد. در عوض، عاملان فرآیندها قرار است تا یک مشکل را –که برخاسته از یک تغییر فناورانه ی اساسی است- حل کنند و سپس مشکل دیگر را- که برخاسته از یک تغییر فناورانه ی دیگر است را- پیش روی گذاشته و حل بنمایند و سپس به همین ترتیب ادامه دهند. هریک از اینها ضروری خواهند بود و بسیاری از افراد نیاز خواهند داشت تا طراحان چیزی را که آنها به تازگی انجام داده اند، حذف کرده و چیز دیگری را جایگزین آن نمایند، که این موضوع بازتاب دهنده ی دگرگونی ضروری ای است که برای فناوری جدید دیگری که سازمان تصمیم گرفته است تا از آن بهره ببرد، نیاز است.
عبارت مدیریت فرآیند کسب و کار (BPM) در حدود سال ۲۰۰۳ عنوان شد زمانی که نوع جدیدی از نرم افزار تحلیل فرآیند اینترنت-محور ظهور کرده بود. این ایده، یعنی مدیریت فرآیند کسب و کار، همان طور که در کتاب سمینار اسمیت و فینگار از آن حمایت شده است، این بود که نرم افزار مدیریت فرآیند کسب و کار (BPMS) امکان پیاده سازی تغییرات فرآیند کسب و کار را فراهم می کرد. فرآیندها در ابزارهای نرم افزاری BPM مدل سازی می شدند و سپس با استفاده از ابزار، تغییراتی بر آنها اعمال می شد که می توانست کم و بیش فوری رخ دهد. مشکل این راهبرد این است که شخص ابتدا باید فرآیندها را زمانی که وجود داشتند، مدلسازی می کرد. این موضوع واقعا برای برخی فرآیندهای اساسی انجام می شد، اما هیچ کس وقت نداشت که این کار برای بیش تر فرآیند های روتین که در بیش تر سازمان ها پیدا می شوند، انجام دهد. اگر بخواهیم واقع بین باشیم، در آینده هم کسی این کار را نخواهد کرد. همه چیز به سادگی و با سرعت زیادی تغییر کرده است.
امروزه مرسوم و محبوب است که درباره ی دگرگونی صحبت شود. تاکید زیرکانه ای که کلمه ی دگرگونی با خود حمل می کند این است که ما با نوآوری های فناورانه ای که یکی پس از دیگری رخ می دهند، مواجه ایم. این نوآوری ها نیاز دارند که ما به کلی مدل های کسب و کار خود را برای زنده ماندن تغییر دهیم.
دگرگونی راجع به بهبود فرآیندهای کسب و کاری موجود نیست. دگرگونی درباره ی تغییر طرز تفکری است که ما داریم کسب و کارمان را با آن انجام می دهیم.
ما به متدولوژی دگرگونی فرآیند چابک و جدیدی نیاز داریم
عاملان تغییر فرآیند کسب و کار به روش مدیریت فرآیند چابک نیاز دارند. به طور هم زمان، آنها به راهبرد جدیدی نیاز دارند که کاری را پردازش کند که نه تنها بر تحلیل جامع تاکید ندارد، بلکه بر تحلیلی تاکید دارد که بر روی اضطراری ترین مشکلاتی که سازمان با آن روبروست، تمرکز دارد- احتمالا مشکلی که فناوری جدیدی که سازمان به تازگی تصمیم به بکار گیری آن گرفته است، برخاسته است.
بنده نمی توانم در قالب تنها یک مقاله، روش دگرگونی فرآیند را طرح ریزی کنم، اما می خواهم تلاش کنم که آن را در مجموعه ای از مقالات، در خلال دوره ی چند ماه آینده، به انجام برسانم. در مقاله ی این ماه می خواهم روی طرح ریزی برخی قوانین کلی تمرکز کنم که برای پذیرفته شدن در دگرگونی راهبردی در دهه های آینده نیاز خواهیم داشت.
- هر روش یا متدولوژی دگرگونی باید بپذیرد که تغییر فرآیند هرگز قرار نیست اتفاق بیفتد – آن سازمان ها هرگز قرار نیست معماری های فرآیند کسب و کاری جامع و کامل داشته باشند و یا اینکه حتی فرآیندهای اصلی کسب و کارشان را توصیف کنند.
- در عوض، هر روش دگرگونی قرار است به گونه ای طراحی شود که اضطراری ترین تغییری را که سازمان با آن مواجه می شود شناسایی کرده و به آن رسیدگی کند. برخی سازمان ها قرار هستند متوجه شوند که باید فرآیند یکسانی را چندین و چند بار در خلال گسترده شدن فناوری ها، انجام دهند به طوری که هر بار انجام فرآیند، بار پیشین را حذف می کند. این بدان معنی است که می خواهیم از روش بالا- به – پایین استفاده کنیم. ما با یک مرور کلی و سطح بالا از سازمان آغاز خواهیم کرد و سپس تمرکز رو به پایینی خواهیم داشت تا تغییرات خاصی را در مکان های مختلف در سراسر سازمان شناسایی کنیم.
(آنچه را که صنعت خودروسازی قرار است با آن مواجه شود تصور کنید. آنها در حال حاضر دارند از بنزین به سوی هیبرید-الکتریکی حرکت می کنند و احتمالا به زودی آن را هم حذف و هیدروژنی-برقی را جایگزین آن خواهند نمود. به طور هم زمان، آنها مجبور خواهند شد که خودروهای امروزی را از میان برداشته و انواع گوناگون خودروهای بدون راننده را جایگزین آن کنند و غیره…)
- هر روش دگرگونی مجبور خواهد بود که چابک باشد – باید مجبور باشد که با تخمین های متوالی کار کند. این موضوع هیچ ربطی به یک طراحی مجدد نوین ندارد، بلکه موضوع اساسا راجع به نوشتن یک پیش نویس و یک پیش نویس دیگر و همین طور ادامه دادن است. یعنی اینکه ما برای فرآیندهای بزرگ طرح های دارای جزئیات ریز نمی نویسیم بلکه به جای آن طرح های سطح بالا می نویسیم و سپس فقط در مناطق خاصی جزئیات را وارد می کنیم.
- بیش ترین تغییری که ما با آن مواجه خواهیم شد، تغییرات مربوط به فناوری خواهد بود – که شامل تغییرات دیجیتالی و شناختی می باشد که مشمول مقادیر فراوانی از فناوری اطلاعات می باشند. طراحی مجدد فرآیند مجبور خواهد شد که در توصیف تغییرات فناوری اطلاعات و نکات ظریف چنین تغییراتی بهتر عمل کند.
بنابراین در یک کلام، چابک (Agile) ، تحلیل از بالا به پایین ، توانایی تعیین اثرات فناوری در سراسر سازمان و توانایی حرکت چابک. این یک فرمان بزرگ است و ما را از بیش تر روش های فرآیند جامع و کُند که امروزه داریم، دور می کند. من تلاش خواهم کرد که در ماه آینده با جزئیات بیش تری صحبت کنم و برخی ایده های خاص را طرح ریزی بنمایم.
بخش دوم نوشته: به سوی BPM چابک (بخش دوم)– نوشته پاول هارمون