دانلود مقاله طراحی مجدد بر اساس برنامه ریزی منابع سازمانی
در دهه 1990 بسیاری از شرکتها اپلیکیشن های رده عام را نصب کردند؛ این اپلیکیشن ها توسط شرکت های مختلفی همچون SAP، پیپل سافت ، بان ، جِی دی ادواردز ، و اوراکل ساخته شده بودند. این فروشندگان در ابتدا بر این تأکید داشتند که اپلیکیشن هایی را فروخته اند که وظایف رایج معینی که شرکت ها با آنها مواجه هستند را انجام میدهند: بعنوان مثال وظایفی در بخش های حسابداری، موجودی انبار، و منابع انسانی. همین شرکت ها سپس در پاسخ به توجه گسترده به بهبود فرآیندهای تجاری، شروع به تغییر جایگاه های خود کردند. آنها الگوها یا نقشه هایی را توسعه دادند که نشان میداد گروه های مدول های (واحدهای) آنها را چطور می توان با هم مرتبط ساخت و فرآیندهای تجاری را ایجاد نمود. در راستای این تغییرات، مردم این گروه اپلیکیشن ها را اپلیکیشن های برنامه ریزی منابع سازمانی (ERP) نامیدند و اخیراً بعضی از آنها اپلیکیشن های مدیریت ارتباط با مشتری (CRM) و اپلیکیشن های تولید را هم اضافه کرده اند. اساساً فروشندگان لایه ای از نرم افزارهای یکپارچه سازی اپلیکیشن های سازمانی یا جریان کاری را معرفی کردند که به شرکت ها اجازه میداد جریان کنترل را از یک مدول ERP به یک مدول ERP دیگر تغییر دهند.
یکی از طرفداران پیشروی این رویکرد، توماس دیون پورت است؛ او یکی از مشاورانی است که در اوایل دهه 1990 جنبش مهندسی مجدد فرآیندهای تجاری را آغاز کرد. دیون پورت در سال 2000 کتاب «ماموریت حیاتی: تحقق وعده سیستم های سازمانی» را نوشت. او ادعا میکرد که یک رویکرد اپلیکیشن های بسته بندی شده (بسته های نرم افزاری) شرکت ها را قادر می ساخت تا سیستم های نرم افزاری خود را یکپارچه سازند و آنها را بهبود دهند. او در توجیه این بحث خود با دقت عمل می کرد و می گفت، استفاده از نرم افزار فقط در یک معماری فرآیندهای تجاری گسترده تر کارساز است اما – طبق اعتقاد دیون پورت – زمانیکه در زمینه ای استفاده شود که اپلیکیشن ها را بسته بندی میکند، می تواند به شرکت ها کمک کند که فرآیندهای متنوع را سریعاً (ترکیب و) یکپارچه سازند.
برنامه ریزی منابع سازمانی و گروه مدیریت فرآیندهای تجاری
شرکت X بدون اینکه خودش بداند در حال آماده شدن برای انتقال به BPMS است. آنها اکنون مدیران و تیم های فرآیندهای سطح سازمانی دارند و با این مشکل مواجه هستند که چطور می توانند ساختار ERP ساده شده خود را حفظ کنند و در عین حال به بخش های مختلف اجازه دهند که فرآیندهای خود را طوری سفارشی سازند که یکپارچگی بهتری با اهداف کلی زنجیره های ارزش اختصاصی خود داشته باشند. یک فروشنده از یکی از مراکز فروش BPMS برای شرکت X توضیح میدهد که BPMS می تواند همزمان دو مزیت را فراهم سازد. این شرکت می تواند از یک محصول BPMS استفاده کند تا وابستگی های بین مدول های ERP را جدا سازد و همچنین سفارشی کردن را در بسته BPMS ممکن سازد بدون اینکه مجبور باشد مدول های ERP را سفارشی سازد. آنها در این لحظه یک نصب منفرد برای یک اپلیکیشن ERP انجام خواهند داد و در عین حال امکان سفارشی سازی فرآیندهای خاص را هم خواهند داشت.
شکل 16.13 نشان میدهد که شرکت X چند سال بعد از نصب یک بسته BPMS برای مدیریت فرآیند فروش خود، به کجا می رسد. در این مورد، فرآیند استاندارد در یک محصول BPMS تعریف شده است. بجای سفارشی کردن مدول های ERP، تمام سفارشی سازی که باید انجام شود در داخل ابزار BPMS انجام میشود. ما اینها را بصورت جعبه های فعالیت 1 و 2 در شکل 16.13 نشان داده ایم (اگر به شکل فنی تری بگوییم، این شرکت می تواند قوانین تجاری را در داخل محیط BPMS ایجاد کند که داده ها را برای ارائه دادن به مدول های ERP، تحلیل و آماده می کند). مزیت دیگر BPMS این است که مدول های ERP را می توان توسط ابزار BPMS مدیریت کرد، نه اینکه همه آنها را با هم کامپایل (گردآوری) کرد. بنابراین اکنون محصول BPMS، ERP را مدیریت میکند و به کاربر اجازه میدهد تا تغییرات را به شکل ساده تری اعمال کند، و شرکت X هم می تواند از مشکلاتی اجتناب کند که در حال حاضر شرکت هایی با سری مدل های کامپایل شده ERP با آنها مواجه هستند. شرکت X احتمال پی می برد که می تواند از سیستم BPMS برای سفارشی کردن فرآیندهای فروش پایه استفاده کند تا از زنجیره های ارزش متعدد پشتیبانی کند، و در عین حال یک نصب منفرد از یک اپلیکیشن ERP را حفظ کند.
In the 1990s many companies installed off-the-shelf applications from a variety of companies, including SAP, PeopleSoft, Baan, J.D. Edwards, and Oracle. Initially, these vendors stressed that they sold applications that performed certain common tasks that companies faced, like those in accounting, inventory, and HR. Later, in response to widespread interest in business process improvement these same companies began to reposition themselves. They developed templates or blueprints that showed how groups of their modules could be linked together to create business processes. In line with this transition people began to refer to these groups of applications as enterprise resource planning (ERP) applications, and recently some have added customer relationship management (CRM) applications and manufacturing applications. In essence, the vendors introduced a layer of enterprise application integration software or workflow that allowed companies to specify or modify the flow of control from one ERP module to another.
One leading advocate of this approach is Thomas Davenport, one of the consultants who had kicked off the business process reengineering movement in the early 1990s. In 2000 Davenport wrote Mission Critical: Realizing the Promise of Enterprise Systems. He argued that a packaged application approach allowed companies to integrate and improve their software systems. He was careful to qualify his argument and say that the use of software worked only within a broader business process architecture, but when implemented in such a context Davenport believed that packaged applications could help a company to rapidly integrate diverse processes.
Enterprise Resource Planning and Business Process Management Suite
Without knowing it Company X is preparing to move to BPMS. They now have enterprise-level process managers and teams and they are now struggling with how to keep their simplified ERP structure, while simultaneously allowing different divisions to tailor their processes to better integrate with the overall goals of their specific value chains. A salesperson from one of the BPMS vendors explains to Company X that BPMS can provide the best of both worlds. The company can use a BPMS product to separate dependencies between ERP modules and to provide tailoring within the BPMS package, without having to tailor the ERP modules. At that point they will have a single installation of an ERP application and the ability to tailor specific processes.
Figure 16.13 illustrates where Company X may end up a few years after it has installed a BPMS package to manage its sales process. In this case the standard process has been defined in a BPMS product. Rather than tailoring ERP modules all the tailoring that needs to be done is done within the BPMS tool. We’ve represented these as activity boxes 1 and 2 in Figure 16.13. (Put more technically, one creates business rules within the BPMS environment that analyze and prepare data to be submitted to the ERP modules. As an added benefit, the ERP modules can be managed by the BPMS tool rather than compiled together. Thus, now the BPMS product manages ERP and allows the user to make changes rather easily, Company X can avoid the problems companies with large compiled sets of ERP modules now struggle with.) Company X may very well find that they can use the BPMS system to tailor their basic sales processes to support multiple value chains, while simultaneously maintaining a single installation of an ERP application.
(جهت بزرگ نمایی روی عکس کلیک نمایید)
فرآیندها، بسته ها، و بهترین روشها
نگاه دقیق تری به SAP
اجرای یک طراحی مبتنی بر ERP
مطالعه موردی: نستل یو اس اِی SAP را نصب میکند
استفاده از BPMS برای بهبود نصب ERP ها
برنامه ریزی منابع سازمانی و گروه مدیریت فرآیندهای تجاری
منابع
Processes, Packages, and Best Practices
A Closer Look at SAP
Implementing an ERP-Driven Design
Case Study: Nestlé USA Installs SAP
Using BPMS to Improve ERP Installations
Enterprise Resource Planning and Business Process Management Suite
Notes and References
- اصل مقاله انگلیسی با فرمت ورد (word) با قابلیت ویرایش
- ترجمه فارسی مقاله با فرمت ورد (word) با قابلیت ویرایش، بدون آرم سایت ای ترجمه
- ترجمه فارسی مقاله با فرمت pdf، بدون آرم سایت ای ترجمه