به سوی روش BPM چابک،تعیین مشکلات – نوشته پاول هارمون
در این مطلب بخش دوم نوشته پاول هارمون در زمینه مدیریت فرایند چابک را خواهیم خواند. در مطلب قبلی (به سوی BPM چابک (بخش اول)– نوشته پاول هارمون) توضیحاتی در مورد مدیریت فرایند چابک و ضرورت اتخاذ متدولوژی چپابک در حوزه مدیریت فرایند اشاراتی داشتیم. حال ادامه مطلب را میتوانید بخوانید.
این دومین مقاله ای است که در آن بر روی سریع تر سازی روش BPM تمرکز دارم.
همان گونه که پیش از این در مطلب قبلی اشاره کردم، واژه ی agile یا چابک برای افراد مختلف معانی مختلفی دارد. تعبیر شخصی بنده از agile ریشه در Kent Beck دارد که راجع به این واژه در کنفرانس های کنسرسیوم کاتر در دهه ی ۱۹۹۰ سخنرانی می کرد. کنت یک توسعه دهنده ی نرم افزار بود که از “روش آبشاری” برای توسعه ی نرم افزار که در آن هنگام محبوب بود، ناامید شده بود. این روش آبشاری در واقع شامل رشته ای از فازها و گام های ناهموار بود. کنت تاکید خود را بر این گذاشت که گامی کوچک بردارد و بخشی از کُد را تکمیل کند و برای انتهای هر روز یا هفته چیزی با قابلیت اجرا داشته باشد. کار او همچنین شامل استفاده از تیم هایی بود که به طور نزدیکی با هم کار می کردند تا بدون نگرانی زیاد درباره ی پاسخ دهی برای زمان بندی های طولانی یا ایجاد مستندات جامع و کامل، به نتایجی برسند. این راهبرد بسیار وابسته به زبان ها و ابزارهای نرم افزاری جدیدی بود که در دهه ی ۱۹۸۰ ایجاد شده بودند و امکان توسعه ی سریع را به همراه کدهای ترجمه شده ی حمایت شده، فراهم کرده بودند.
کنت و چندین مهندس نرم افزار دیگر که داشتند این راهبرد غیررسمی تر را ارتقا می دادند، به کمک یکدیگر بیانیه ی برنامه نویسی چابک (Agile) را به رشته ی تحریر در آوردند که در واقع طرح کلی قوانین بنیادی جنبش توسعه نرم افزار چابک می باشد. برخی نکات کلیدی شامل موارد زیر می باشند:
* افراد و تعاملات – به جای فرآیندها و ابزارها
* نرم افزار کاربردی _ به جای مستندات جامع و شامل
* همکاری مشتری _ به جای مذاکرات قراردادی
* پاسخ به تغییرات _ به جای پیروی از یک طرح
اگر این ایده ها را بر دگرگونی فرآیند اعمال کنیم، احتمالا بر راهکار غیررسمی تری برای طراحی مجدد فرآیند تاکید خواهیم کرد. روی تیم ها، انجام سریع کارها، آزمایش آنها و سپس سعی در راستای تکراری دیگر تاکید خواهیم کرد و تلاش خواهیم کرد تا تلاش های مربوط به مستندات رسمی را به حداقل برسانیم.
همان طور که قبلا اشاره کردیم، این راهبرد در تقابل با روش های رسمی فرآیند است که بر توسعه دادن یک معماری و جستجو در یک سازمان برای یافت موقعیتها، تاکید بیش تری دارند. مهم ترین پیشران برای این تغییر، نقش فزاینده ای است که فناوری های دگرگونی پذیر در سازمان های ما دارند بازی می کنند. جایی که در گذشته ممکن بود بخواهیم اصولی تر و قاعده مندتر باشیم، امروز به شکل فزاینده ای با اضطرار بیش تری تحریک می شویم. فشار مبرم نیاز دارد که فناوری جدیدی را پیش از آنکه استفاده از آن توسط یک رقیب، سازمان ما را به عنوان واحد کاملا بی فایده ای جا بزند، به ثمر برساند. این اضطرار ما را وادار می کند تا به تلاش های در راستای تحلیل ریزتر و دقیق تر که مدتها پیش مرسوم بود، بی اعتنا شویم و از فناوری هایی استفاده کنیم که یک تیم می تواند از آنها بهره ببرد تا موقعیت ها را برای استفاده از یک فناوری کاملا جدید، با سرعت بیش تری شناسایی کند.
در این اولین مقاله درباره ی راهبرد BPM چابک، به یک مسئله پاسخ خواهیم داد: تعیین موقعیتی که می تواند توسط فناوری جدید به آن پاسخ داده شود.
فرآیند جدید
همه چیز با تیمی شروع می شود که وظیفه اش این است که تصور کند چگونه یک فناوری جدید، فرآیندهای کسب و کارهای شما را تحت تاثیر قرار خواهد داد. اگر سازمان دیگری از قبل از این فناوری استفاده می کرده است، پس شما می توانید از کارهای سازمان دیگر ایده بگیرید. شما می توانید توصیف کنید که آنها چه می کنند سپس سعی کنید که تصور کنید شما چگونه می توانید آن را بهتر انجام دهید. اگر قرار است اولین نفر باشید، پس باید با برگه ی کاغذ سفیدی آغاز کنید و تصور کنید که فناوری جدید چگونه سازمان شما را تغییر خواهد داد.
اجازه بدهید اینجا مثالی را که می دانم عنوان کنم، زیرا من مشاور سازمانی بودم که تغییر اساسی را بر عهده گرفتند. در اواخر دهه ۱۹۷۰، بانک ها شروع کردند به استفاده از ATM که به مشتریان اجازه می داد تا امور بانکی خود را از طریق ماشین انجام دهند. قوانین در ایالات مختلف مقررات را تعیین می کنند. به عنوان مثال در برخی ایالات ماشین ها می توانستند به صورت مستقل از بانک در گوشه ای قرار داده شوند ولی در برخی دیگر، مانند همان ایالتی که من در آن کار می کردم، ماشین ها باید حتما در مجاورت یک بانک احداث می شدند. در ایالت ما، ما باید به این فکر می کردیم که ماشین ها را در کدام قسمت بانک های موجود قرار دهیم. ما می دانستیم که ماشین ها ۲۴ ساعته در هفت روز هفته کار می کردند، بنابراین باید فکر می کردیم که چطور آنها را در خلال آخرهفته های شلوغ که آن شعبه ها تعطیل بودند، پُر از پول نگه داریم. بانکی که من در آن کار می کردم، اولین بانکی بود که در ایالت ما این کار را انجام داد با اینکه سایر ایالت ها ATM را نصب کرده بودند و ما می توانستیم از آن ها ایده هایی را بگیریم.
به عنوان مسئول فرآیند ها، من عضوی از تیمی بودم که روی این مسئله کار می کردیم. در ابتدا من به آرامی می نشستم و به حرف های تکنسین های ATM که درباره ی ماشین ها و راه های نصب آنها در شعب موجود صحبت می کردند، گوش فرا می دادم. تیم های مخصوصی باید ایجاد می شدند برای آوردن پول به ماشین ها و غیره.
بعد از حصول درکی درباره ی اساس این فناوری که باید به کار گرفته می شد، در حالی که برخی از اعضای تیم شروع کردند به تمرکز روی تغییرات برنامه نویسی برای سیستم های نرم افزاری بانک، من شروع کردم که بر روی فرآیندها تمرکز کنم. از آنجاکه ATMها باید ۲۴ ساعت روز باز می بودند، این به آن معنا بود که حساب های مشتریان می توانست در هر زمانی به روز رسانی شود. سابق بر این، حساب های مشتریان تنها می توانست در “ساعات کاری بانک” به روزرسانی شود. بنابراین ماشین های ATM تغییر بزرگی را در تفکر متخصصان نرم افزار در باره ی فرآیندهای به روزرسانی حساب، ایجاد کردند. در حال کار با سایر کارکنان شعبه، در نهایت به یک لیست شامل ده فرآیند کسب و کاری رسیدیم که نیازمند تغییراتی بودند. راهی متفاوت برای اندیشیدن راجع به این موضوع این بود که بیش از ۲۰ نفر نیازمند می شدند تا چیزهای جدیدی یاد بگیرند تا بتوانند کارهایشان را انجام دهند. برخی کارهای موجود باید تغییر می کردند درحالی که برخی کارهای دیگر اساسا باید ایجاد می شدند. در همه ی موارد لازم بود تا گام ها و روندهایی را تعیین کنیم که می توانستند به شیوه ای متفاوت انجام شوند. این شامل مواردی چون تعلیم اپراتورهایی برای پاسخ گویی به سوالات مشتریان درباره ی تراکنش هاشان با ماشین های ATM و آموزش افراد برای نشستن در بانک های تلفنی و پاسخ گویی به تماس های راجع به مشکلات ATM می شد. (مثلا سگ من کارت ATM ام را جویده است، اکنون برای گرفتن کارت جدید چه کنم؟)
ما نهایتا به لیستی راجع به فرآیندهای اصلی کس که باید تغییر داده می شدند، رسیدیم و سپس برای چندین پروژه ی بهبود فرآیند موازی که باید به کار می بردیم تا اطمینان حاصل کنیم که فرآیندهای جدید در زمانی که ATMها واقعا برای استفاده آماده شده بودند، آماده ی اجرا بودند، یک زمان بندی ایجاد کردیم. در آن زمان، این موضوع پیشران یکی از بزرگ ترین بهبودهای فرآیندی و پروژه های آموزش کارکنانی بود که در یک بانک به کار گرفته می شد. علاوه بر این، از آنجا که مدیریت ارشد می خواست اولین واحدی را داشته باشد که ATM را در ایالت پیاده سازی می کرد، پیاده سازی فناوری در واقع پیشران برنامه زمانی بود و همه ی تلاش ها برای تغییر فرآیند، تحت فشار قابل توجهی بودند.
مایلم بگویم که بانک از قبل همه ی فرآیندهایش را همراه با فلوچارت ها و مستندات دقیق به خوبی تعریف کرده بود، اما یک جای کار ناقص بود. علاوه براین برای افرادی از ما که روی پروژه کار می کردیم، واضح بود که ما زمان نخواهیم داشت تا مدل های فرآیندها را با جزئیات کافی برای فرآیندهای گوناگونی که باید تغییر می کردند، توسعه دهیم. درعوض، ما مجبور بودیم که روی فعالیت های خاصی که می دانستیم نیاز به تغییر داشتند، تمرکز کنیم و آنچه را که برای حمایت از تغییرات خاص مورد نیاز بود، توسعه دهیم.
به بیان دیگر، ما می دانیم که فرآیندها باید تغییر داده شود به گونه ای که این فرایندها می توانستند با پرسش های جدید مشتریان سروکله بزنند. با این حال، ما به دنبال این نبودیم که کل فرآیند های مرتبط را تعریف کنیم. ما به سادگی فعالیت های خاصی را مانند پاسخ به پرسش های مشتریان تعریف کردیم و بر تغییراتی در آن فعالیت ها تمرکز نمودیم. به شیوه ای مشابه، ما فعالیت های Platform Officer را گسترش دادیم تا فعالیت جدید کمک به مشتری برای درخواست کارت ATM را شامل شود. در همان زمان، به همه ی کارکنان آن شعبه ی بانک ATM ها را معرفی کردیم- هر کدام کارتی گرفتند و یاد گرفتند که چگونه سپرده گذاری را انجام دهند و پول از ATM بردارند و غیره.
برخلاف یک تحلیل فرآیند سنتی تر که در آن از ابتدا شروع می کردیم و کل زمینه ی کاری را معین می نمودیم،_ در این مورد ما بسیاری از بخش هایی را که ممکن بود مجبور به انجام آن باشیم، از قلم انداختیم و بر روی فهمیدن تغییراتی که فناوری جدید قرار بود ایجاد کند، تمرکز کردیم و سپس مکان هایی را که فناوری قرار بود در آن ها تغییراتی را ایجاد کند معین کردیم و تصمیم گرفتیم که چگونه با تغییرات خاص در فعالیت های خاص کنار بیاییم. این کارها فقط و فقط در یک فلوچارت و تحلیل دقیق همراه با جزئیات خلاصه نمی شد، اگرچه که در مواردی از اینها هم بهره می بردیم، اما کار ما عموماً مسئله ی کار با یک تیم، یک فناوری و با کارکنان آن شعبه بود. ما طرح های مختلف را در نظر می گرفتیم که از مشتریان و کارکنان، قرار بود خواسته شود که چه کارهایی را به شیوه ای متفاوت انجام دهند.
ما در حین استفاده از برخی نمودارها، بیش تر تغییرات را همراه با لیست مستند می کردیم.
همانطور که پیش تر قید کردیم، رویکرد تیم ما در انجام پروژه های مدیریت فرایند، بصورت چابک است.
سخن بزرگانی مثل اقای پاول هارمون، بیش از پیش موید رویکرد اتخاذ شده توسط تیم ما است.
کسب اطلاعات بیشتر در مورد رویکرد انجام پروژه های مدیریت فرایند توسط ما