Introduction to Enterprise Systems-ERP : A Guide on How to Manage and Deliver a Complex Project | Ahmed Fawzy | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Introduction to Enterprise Systems-ERP : A Guide on How to Manage and Deliver a Complex Project

teacher avatar Ahmed Fawzy, IT Transformation Advisor

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

8 Lessons (46m)
    • 1. Introduction

    • 2. 1 Introduction to ERP

    • 3. 2 Discover the Current Processes

    • 4. 3 Project Keys to success

    • 5. 4 Business Case

    • 6. 5 Project Delivery

    • 7. 6 Strong Governance Model

    • 8. 7 Organizational Change

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

Learn how to implement a successful ERP project

ERP System is a significant change in any organization. It is considered a business operation transformation—almost ALL companies globally, either implementing ERP or planning to implement it. And because of that, ERP knowledge is critical for IT success.

 In this class, you get the answer to the question, “How do I implement ERP successfully?”

This Class describes an overall approach to implement an ERP system. It will allow you to get the desired results quickly and accurately.

The Class is for Managers and executives. It does not require any programming knowledge, nor does it require prior experience with ERP.

In this class, you will:

  • Get an Introduction to ERP
  • Discover what you have and your starting point
  • ERP Project Keys to success
  • How to plan your ERP Roadmap.
  • How to build an ERP Business Case
  • How to ensure a successful ERP Project Delivery
  • How to build a Strong Governance Model
  • Change management and change adoption  

Meet Your Teacher

Teacher Profile Image

Ahmed Fawzy

IT Transformation Advisor


Ahmed Fawzy, is an Advisor, Author, and Online Trainer. He has 18 years of experience in the fields of IT transformation. Utilizing a unique approach to achieve a better alignment to the business through solutions and processes. Also, how to transform IT organizations successfully from "Traditional to Digital."

Ahmed holds ITIL Expert certification and ITIL4 MP. He is also a certified Project Management Professional (PMP), TOGAF 9 Certified, and has a Master in Business Administration (MBA).  He has implemented improvement programs for a wide variety of organizations. His approach is unique because it doesn't require new additional software or hardware,  "It's simple few adjustments that yield a high return." Ahmed's goal is to help leaders transform their IT internal o... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Introduction: In this brief course, you will get an introduction to what an ERP system is and why all enterprises are looking to implement the ERB. Not only that, but you will also learn how to start the information gathering phase, what you should expect, And a quick overview of how it should be done. You will also get an overview of the best practices for the implementation. This overview is technology agnostic. In other words, it can be used across all technologies. It focuses on the core knowledge required to deliver a successful ERP implementation. Join me in this quick overview to jumpstart your ERP knowledge. Okay. 2. 1 Introduction to ERP: An enterprise system is a system that cuts through the enterprise business functions. Start with sales cycle, operation cycle, a char cycle, and events that delivery cycle. In other words, the logistics going through all of these layers is difficult. And if you notice, a lot of enterprise system implementation is only partially implemented or even failed altogether due to complexity and the delivery. So we need to understand what is an ERP. But before we understand what does an ERP is, let's address why organization think of an ERP system, what improvement doesn't promise. And an orange organizations, the visibility of information is critical to the decision makers because they need to make a decision on the fly to respond to a different state of the market is or to lodge an issue or to take an opportunity. The fragmented system does not allow that because it's not one place to generate a meaningful report. This is y. And organizations attempt to implement ERP solutions. Mainly, they do it for three main reasons. Availability of information, understand the interactions inside functions, across functions and with customers, and finally, reduce waste. Enterprise resource planning system is a significant project in any company. Typically, the duration is based on a couple of things. How many modules in the company you will implement, and how many functions and users accompany have. But the average duration for a standard ERP implementation is three years to five years. If implementation is on the larger side. If you witnessed an ERP implementation, you would notice that the binary extraction or other worlds, the installation takes only a few days. Most of the time, it's customizing the systems to match the process and the functions of the organization. Not only that, but usually after the deployment to production, a team of subject matter experts say to maintain such system due to the long duration of the implementation, the scope usually drifts and the people commitment to the project. So it's critical to focus on the culture change management and try it in sprints instead of Big Bang. In other words, focus only on one process, only even part of it. You don't have to implement the whole process. We need to understand a couple of terminologies to be able to grasp how the organization functions. First, what is a process? A process is a transformation action toward one or more goal. It's measurable, has a specific results and has a specific trigger to start it. Next, we need to learn what is an organization capability? It's a specialized processes, zone one process, trying to achieve a specific goal to benefit the whole organization. And it's not only limited to information technology. For example, capacity management is an organization capability, not a process. Capabilities are like processes. Usually they are experienced, driven, and knowledge intensive. Like for example, financial capital, infrastructure and application. It's easier to obtain resources then capabilities. Capabilities develop over time from solving problem, finding solution, dealing with risk, and analyzing failures. So now, what is a business process? This is a process from the basic building blocks of the business, like for example, raw materials until fulfillment of a customer order. And Oster cells are support. It's going through all the sub-processes in the middle, like sales, manufacturing, materials, staging, transportation, loading, and finally, delivery. This typical presented in a swim lane diagram to present how the overall process is functioning. And in each function, one or more flowcharts represent a specific process area. So what is a business function? This is like sales, marketing, HR, production, finance, procurement. Each one of these functions has their own processes to function correctly. One of the main issues is a business face is a silo effect, which means that each function doesn't talk to other functions too much and their entire process is only inside that specific function. To solve this issue, you need to have a process-oriented view of the organization. This is why there is a need for an end-to-end enterprise system to link all silos together and link all the business processes together. Any company exists for a reason, is auto-generate profit or to create some social value. In all cases, companies fall under three main categories is our manufacturing. You are a product company upstream. You are creating some product that will be used in another product. This could be, for example, Preparing raw materials, preparing components, preparing parts, but you are not dealing with a customer or a final customers manufacturing product accompany downstream. You're creating a product that would be sold to an inducer. And finally, you are a service company. Each one of these companies might have some of the basic processes. Usually the business process is triggered by some activity or a specific trigger, like a specific time. They ERP system is usually divided into modules. Each module is considered some sort of an independent software and usually has its own setup and licensing. A module can cover one or more business functions and comes with a standard, the processes to cover a typical setup of such a business function. And usually this is will be your starting point. You start whizzes, recreated processes, and moved from this point forward. The challenge, if you developed an organization capability and one or more areas, this means you are doing things in a different way than a typical system. And you need a lot of customizations match the process you currently have. Ignoring this fact would result in accompany losing such capability. So it's essential to determine the gap between the standard of the process that came with the software and the running process. You have it already in your organization. And finally, address and adjust any app. Now based on the software you will be using, Oracle, CP, or Microsoft, or whatever flavor of an ERP will have. You will have a different naming for the modules you will get. But as mentioned, you will have each area of the business. Each area will have its own processes. Usually, the core modules are. Hr, payroll, order management, sales, transportation management, enterprise asset management, product lifecycle management, manufacturing, finance, CRM, project management, procurement, supply chain management. Some of these modules overlapping each other based on which technology you are working with. But generally, these are the common ones available across most vendors. Sometimes you will find one over the modules are sub-module of another module. For example, B-roll sometimes come under HR and some softwares. So it depends, but xi's are usually the typical functions you will find the system when you implemented initially comes out as blank and you define everything from scratch. So let's have a quick overview of three processes as an example. First, let's understand what is a procurement process. This process goal is to acquire the needed product, service, and material externally to create a finished product or service. This process trigger is usually warehouse low material, new order in case of ordered manufacturing scenario, sales forecasting, and finally, business plans. And the largest care enterprises, you will have a procurement department and the purchasing department. In this case, a procurement function is to aggregate all the requests and select the top suppliers and send it to the purchasing. The purchasing start to process and find the best uprise versus quality issues a, B O, and receive the goods to our house. Then we would receive the vendor invoice, which will be directed to the accounting. Next we have production process. The production process is acquiring the needed products and services internally. Do manufacturer the final product required. And the triggers are the same triggers as a procurement. But in addition, the warehouse can order finished goods. If the stock is falling below a specific threshold, then the production requests from the warehouse, the material needed for production, then either the warehouse would supply it directly or go through the procurement process. Once the materials are received, the production of the goods is started and the product is created, and the finished product is sent to the warehouse to be stored for future orders. Finally, we have the third one, business fulfillment of process. This is a tree structure used from top of the company all the way down to every basic component ends the system and where it exists. This will differ based on the software, but it follows an organization chart structure. At the first look, you will have that at the top, the enterprise name. This is the parent company that has lots of companies underneath that. For example, Dell has VMware and Dell EMC as a separate companies, but both under the enterprises. Next you have the company level. This is the company under the enterprise like VMware and Dell EMC in our example. Next you have the branch. This is a branch for each of the companies. This is considered a reporting unit like an East Coast Branch. And finally, you have the locations are the smaller locations under this specific branch, like for example, the showrooms or the small warehouses reporting to the specific branch. Now this hierarchy is also used in both bills, NAS fulfillment, and to build the sales organization. The more granular the organization will be, the more capabilities on the reporting you will have. In sales, you will have one other part which is the distribution channels. This is like online store, wholesale, retail, etc. Now, underneath all of that, you should have some items can be called MiniZinc based on which software you are using. These items are used across all enterprises, like different types of raw materials, different customers, and different suppliers, or some software calls him vendors. As you noticed, these are items that used over and over and over so you can read at one time and then you will start cuz it multiple times. Now, as you might have noticed, this is a huge transformation project. And in such larger project, sometimes you get lost. Abit later, we will discuss how to make an ERP projects succeed. But for the time being, your starting point is always where you are, the current processes you are currently have. And this is where b is a topic for the next video. Thank you for watching and see you next video. 3. 2 Discover the Current Processes: The first step is to know where's organization is before thinking of improving or adjusting the current setup. Any uncle collated move, trying to enforce a process or developing capabilities that contradicts with the business will result in a project failure. Your starting point is to recommend the current process and system using multiple diagrams. And this typically is a business analyst role or the functional consultant. If you don't have a business analyst in your organization, the idea behind the building of these diagrams is to have a reference point to get back to what is needed. Typically, hundreds of processes exist in any given organization to upgrade or modify some component it's required understand who's dealing with this component ends a deta used a deeper understanding of entities, activities, and Dataflow is required to decide because as mentioned in young calculated move might break down the integration between multiple processes and they're in a business function, two are useless function. So how to Documenta current systems? There is a high chance that the organization documentation is out of date. So how to document the existing system? Usually, if you have a recommendation organization is not up-to-date. Maybe some consult on didn't awhile back and it is not updated sense though. I will not get into the details of how you actually recommends a system. I will give you an overview of the process that typically a consultant does. So at least you can govern the consultant or have an understanding of how a consultant will function. The sudden point is creating an activity list. These are simple interviews with the owners of the functions. You take one interaction and start drilling deep. Go to the owner in case of no not available, go to the frequent user and ask how to do a process with all its variation. This is like playing what if scenario. Whenever a new branch comes off, one of the activities, create a new list for it, the commands and additive, and started building the activity table. After building couple of activity lists, your next step is to build a context diagram. Context diagram provide a visual view. Our high level at a glance. It's a view from internal to external. The internal entity can be the organization end's external suppliers and banks for example. Or it can be Department team, system process within the organization interacting with external entities for that specific department team system or a process. Think of it as us or them diagram the external entities, not the focus of the context diagram, however, it can be analyzed later. Each arrow represents a process or a subprocess. Start by drawing the first context diagram with the organization and external entities. Who's your organization is dealing with? Each of the relationship, finds its internal entities, and draw its context diagram. Keep doing this until no more entities have a context diagram. This diagram is meant to define system boundaries. The context diagram is logical abstract diagram. This mean it's high level diagram. Once you draw the context diagram, you draw next the physical data flow diagram, or D BE DFD, physical data flow diagram is following the exact steps from the activity list the consultant created ends the first step. So simple way of doing it is taking the context diagram and remove the internal process or the internal entity, replacing it with all the internal activities. Next, you have your logical data flow diagram. A conceptual diagram is focusing on the activity and who's doing them. In this diagram, we group activity based on the location and time of execution. Growing these three diagrams will give you a detailed view of how the system function and what interactions are there. And we'll make a drawing the flowchart, a much simpler process. So now the consultant, armed with all of these information, you start drawing a flowchart. Things should be getting clear at this point ends a consultant understands the process clearly. Z usually either proceed to draw a flow chart or a swim lane diagram. So what does a flowchart? The flowchart is a representation or a start and end of a process that contains some logic inside it. It gives a picture of the steps in necessity for a specific action. So what is a swimlane chart? Women chart is a high level with lots of subprocesses. Each subprocess has its own flowchart. As a rule, if an entire process is performed by a single actor or an entity, you will stop down traditional flowchart if has many actors or, or many entities, in this case, use swimlane if it's complicated with so many steps, you'll swimlane to demonstrate the interaction between actors or entities. And for each actor, use a flowchart. Since our example is simple process, we will use the swimlane to cover all activities. Thank you for watching and see you in the next video. 4. 3 Project Keys to success: At this point, you decide on which modules of the ERP system you will implement and you understand the process in this function area very well. You have your flowcharts and your swim lanes. Now you move to the project execution. Starting from this part, I will discuss the keys for success in any given ERP project. First, the keys to delivering a successful ERP implementation is a bit different from any other project due to the scale of the project and the transformation requirements. But in a nutshell, you have seven areas that need focus to deliver a successful transformation to your ERP system. First, strong multilayer, the governance, clear business case. Ui developed with users, program plan and monitoring the entire project must have a change management process in place. Tested plan to transition to the migration and practice our joy when possible. Let's drill down on what's required to ensure a smooth delivery. I will try to group these seven areas that make them more practical. First, not having a plan. Usually since the organization is functioning, this mean it already has some system to be able to function correctly. Having a roadmap of how the new centralized ERV system we replace each distributed system will allow more smooth ERP implementation delivery. And also, you need to plan how you will decommission z Systems as well. The choices for such areas are, leaves the old system working as usual and the ERP is working side-by-side. But this one, you might be running into a risk that the users will simply ignore the new system and we'll continue using the old system. Next you have the whole system is running to get the legacy information, but no more edits and sided. But then your transactions is on the ERP and any numeral transaction entered in the old system is simply ignored. Finally, it's all system is removed with data migrated to ERP or starting from scratch, no data migration. Each application would have its own set of challenges. Let's take an example. The data of an old system will be transferred to an ERP system. Or there will be a cut over period between the old and the new system. Or the data can cause an issue in the new system. And it's better just to ignore it and start from a clean slate. It's never recommended to perform a big bang implementation. It's always recommended to reform a basic setup Ambari for my delta changes to match each process the organization has. In other words, do the implementation in the adjoint manner. Now we need to group both the systems and the process involved and prioritise both to reach maximum business benefits. You started with the process. You already have the side on the gaps between what you have and the standard installation. At this point you have two choices also. Those at least effort to process, to cover as much ground as possible and roaster form into the ERP system or prioritize or processes based on the business need. Each will have its own browse on columns based on your situation, but both are usually considered the corrected choices. Erp implementation involves a complete business transformation. This means it is not a success overnight. It's a transformation target that the business transformed ward in a slow progress transforms operation into a better and more efficient operation targets and allow future growth and success. They ERP system is not just another IT project. As mentioned, it's a business operation transformation projects, both business and IT work together to enable such a transformation, a clear objective of the ARP solution is critical for successful delivery. A project without a clear objective will not result in something useful. This is why a good business case is critical requirement for a successful delivery of the project. Thank you for watching and see you next video. 5. 4 Business Case: A good business case is critical requirement for a successful delivery of the ERP project. So what is a business case? A business case is a demonstration of a business need or requirement that justifies the investment and time, effort and capital to achieve a specific award. The business case is have marketing and have technical. Its purpose to acquire support around a specific problem or requirement, or to deliver a specific value. The business case is critical in any ERP implementation because it will act as a compass that will push the requirement in the specific direction. Without it, the implementation will be aimless and implement ERP for the sake of having an ERP which usually result in a project failure. So how long to build a proper business case? Typically, building a business case would require three to 5% of the total project time. If the plan is to finish the project in 90 days, the business case should not exceed one week. The more time spent on the business case is a better indicator of the expected project duration. Because the challenges you will face in building the business case will be the same challenges you will face in delivering the project, but it will be magnified and to the power of ten. So how to build a business case? You have fix it topics, but feel free to add any additional sections. But don't exceed few pages long, two or three pages max, because many people were reads his business case, mostly executive first, the executive summary paragraph explaining the purpose of the business case typically is written by a business person at the last piece of the document, problem, definition or analysis of the situation. What issue does the business face? Goals? What are the desired outcomes? Solutions? What are the option to solve this problem? The proposal solution to the problem mentioned in earlier steps in each of the Yushin define assumption. Since you are committing to something in the future, you can not be aware of all the information all the time. It's good to blaze some assumptions to make sure that the project will proceed as expected outcomes and benefits. What is the benefit of this specific option cost? How much it will cost for that option timeline, how long it will take for that option to be implemented. Risk assessment. What are the risks of deploying this option? Recommendation? Listing all options at one section for recommendations and why one direction is recommended. Appendix E is this one is optional in Appendix C, add financial analysis. Losses is the most challenging part of the business case. It would be very positive support as a business case with numbers like revenue, Total Cost, breakeven point, fix it coast payback period, Net Present Value and Internal Rate of Return. Thank you for watching and see you in the next video. 6. 5 Project Delivery: Now we move to project delivery. The sanding on how you will deliver the ERP implementation is critical to the return add value and how fast the change will yield the results. But first, you need to understand the basic concept around project delivery. First, you have project delivery methodology in any project, three constraints exist. Scope, schedule, and cost. Changing. One will change the other two as well. The idea of project delivery is how to get from one state to another and how to manage the project to move from the as is, which is the current setup you have now 2a, b, which has a future state you are planning to get to. Two methods are available. You have Waterfall giant. First, let's discuss the waterfall project. It's a project was singled direction flow. The project only moves to the next step once the finished through the current step. This is the traditional way of delivering a project and it's been around for ages. Next you have the agile project. This is iterative project, mean doing the planning and closing only once, but the remaining will go in circles until finishing the project. Sprints are loops the project goes into to produce the value. The shorter the better. The typical sprint duration is two weeks with maximum off for weeks, adjusts these values to fit the project needs. Most Agile or waterfall work under the umbrella of program management. Program management is the practice of grouping two or more projects that deliver similar deliverables. In other words, the program is a special kind of project. It's deliverable, is a deliverable of running projects within. This means, if you are implementing a complete ERP, it will be a program, not a project, and each of the modules in the ERP would be an independent project. So why run a program? The main reasons to run a program instead of several separate projects are dependency between projects inside the program, which is a caissons ARP, managed costs, coordination between activities, between projects, and finally, solve conflicts. Erp modules integrate with each other without a program to ensure that integration is done correctly, you'll be faced with partial integration or even silos inside the ERP system, the most important person in the program management is a program manager role. The role of the program managers is to manage the project managers running the projects in this program. The outcome of the program and the projects running within are the responsibility of the program manager. So he's mainly concerned of delivering the value to the business, not the technical aspect. So what are the program lifecycle? You have three main lifecycle phases. First, you have programed definition. Next, benefit delivery. Third, program closures. Let's start with program definition. Define the value and the benefit of the program. Start onboarding project, started this phase by the program business case, why the program is required, what is expected benefits and assumptions? The second most crucial step in this phase is to define the program governance board. This is a virtual board, consists of the sponsor and the critical stakeholders. They are responsible for changes to the program objectives and benefits. The fine, what's the program should accomplish? How to keep the program on track, House organization, support the program. So what is the benefits delivery from the program? Once a projects are initiated, the program ensures a value is continuously delivered even after the project closure. In this phase creates the benefits register. The benefit register, collect and list all the planned activities. And finally, you have program closure. All projects delivered the expected benefits successfully, if not A-delta project is created under the program to close any gap. This is why deciding onto going with the program when deploying ERP is critical. This is not a project. One critical factor for the correct project implementation is to have an experienced project manager, preferably someone who had previously delivered ERP implementation. The issue of having a project managers that did not deliver ERP solution before is z might not define the risks correctly and it will fall on the subject matter expert to define such risks. This is a problem because of two things. First, the SME time, the subject matter expert time usually is filled with Azar activities. So didn't give enough time and attention to this specific task. Sometimes SME don't know project management and they don't understand the reason behind this activity. So an ERP experienced project manager is essential. But if you don't have such an option, then you will need to assign some of the SME time to align with the project manager and explain the ERP parts and the implementation risks and dependencies. Thank you for watching and see you in the next video. 7. 6 Strong Governance Model: Erp implementation is usually multilayer. This means it goes both vertical and horizontal across functions and across different teams as well. Your primary essential role is to define the roles and responsibilities of each of them and who's the owner of each area. For example, finance is a function. Underneath the finance, you have an account receivable and account payable. Each of these are different process areas that would be implemented. So each one of those, neither owner and are not nice, each of these areas you will have the operator in this case would be the clerks. Zis will be the final solution owners. That will actually makes the data inserts. So to ensure you have a strong multi-layered governance area, you need to define each area owner by building what's called a RACI matrix. Raci matrix as well as you build an organization structure from the process view, the organization structure will identifies escalation procedures or was that a specific process? Your first step is to define the roles that will be part of your implementation. If you have some system integrators that will do the implementation, they should have these functions and you should have at least two persons shadowing them to understand exactly how the system is built for the implementation of the solution, you need at least the following Grohl to ensure successful delivery. First roll program manager. This is the person responsible for the project delivering the required value. And each project is implementing a specific module is doing well with other areas. Solution architect. This is the person responsible for delivering the whole picture. The entire ERP system project manager is a person to ensure the project on time and within budget, showing the expected results. Functional consultant. These are the consultants who understand the specific business function and reform the process mapping of such functions. Usually they are the ones buildings of flowcharts. And technical consultant xi's are the technical team that performs a configuration of the system based on the input from the functional consultant. And finally, you have solution consultants determined the gaps and the integration points between multiple processes across multiple functions. Usually the functional consultants, technical consultants are one-person, plays two roles in sequence. And if the implementation is on the small side, they can manage the solution consultant as well. But usually is a solution consultant role is a different person. If you are deploying one or two modules, you don't need a program manager in this case, or a solution architect, even. But if you are planning on reforming the implementation on the larger side, then in this case you definitely need both. There are two more roles. You need to define what those roles are. Internal roles. They must be from your organization, the process owner rule. This is the person responsible for one specific process and how it should flow. And the functional owner, this is a parent functions that relies on multiple processes to be able to operate correctly. So in other words, the functional owner. Multiple processes on Mars reporting to them. This has nothing to do with the organization structure. Sometimes a functional owner is the manager, and sometimes they are not. Once you determine the roles in your organization, who will do what or work with a system integrator to define such roles. You proceed with building our responsibility matrix. So what is our responsibility matrix? Any typical implementation will have lots of parts. Defining who will be is a team responsible for each area will help you analyze if you will have an issue down the road. There are mini responsibility matrices available with mini variation. The most common is addressee RACI. To build RACI matrix or any of its variation, you start by building a column and rows. The column is built by libeling column header, which will be a team member or the job function. Here, you will list all the names of the team members involved and define in the previous step. Next you have the rows and the rows. You list activity, services, whatever necessary. And this, you will define the parts of the implementation, or maybe even each function or process in each cross-sell fills the responsibility. Always use people names, not job functions. This will enforce the accountability you have to fill with responsible. That one will execute the action accountable, the final approval, typically a team leader consult a subject matter expert. In form. Someone to be informed, support. Someone will provide input to the task, can support the responsible person for the task. Verifier, someone will vary data outcomes. Amber provide quality assurance and out of the room, not included as tasks. Sometimes out of the loop becomes a dash. Additive or responsibility necessity for the team or the project. The two critical ones that must exist in every matrix is responsible and accountable. When filling in the matrix, there can be only one accountable bear item, and one responsible has as much support and consulting as needed, but always want accountable. And one responsible, preferably not the same person for separation of duties. And to have a clear escalation process. Avoid having the single person responsible for all or accountable for all activities. Use blanks if the team is large and lots of people will not contribute to an item. Now, you preform role analysis. Once you build these metrics, someone with too many 0s, you have to segregate these role. Someone was too many r's. If this is too much responsibility for one person. Usually in any organization, you will have a few people that are considers a go-to guy for a specific action. In such a case, you need to segregate these people and to have dependencies on other people's as well. No empty cells in the matrix. You have to consider as this is required for this person to be involved in all items. The role analysis will help you to know, do you have a big enough team to do the implementation as you wish or not, you might adjust the plans to meet the team capacity, sometimes adding more resources as not possible because this is a specialized area or you have a very few people that you consider go-to guys. And usually there is a shortage in the skill set and the market. So it's better to adjust the plans, reduce activities, or reduce the rows. If adding more team members is not an option. Moving slow, but sure is much better than moving fast, but perform lot of fixes down the road. So if you cannot increase the number of people, in this case, you have to reduce the number of tasks or activities. Next, you need to define the communication and reporting plans on the project. How to communicate the right message to the right people at the right time. Usually, communication plan is created by the project and the program manager. A typical communication plan contains stakeholder name, title, project role, key interest in the issues. But refer to communication approach, email, phone in person, et cetera. Messages needed presentation, project update. How often the need the message. Channel, a meal for number, et cetera, delivered by who's responsible for sending exists. Enforcing these plans will ensure the project were not good arc that everyone in the team can reach everyone else. And you as an owner of the project, can actually follow up on the progress easily. Thanks for watching and see you in the next video. 8. 7 Organizational Change: Erp is an organizational change. Change implementation require much behavioral modification. And if you did not change the behavior of the people, simply, they will slide back to the old system or you will be faced to assess significant resistance to organizational change is adoption of a new idea by the organization, in this case will be the AARP. Successful organization change requires that the organization can create and implement new ideas before the actual change happen. The team mission is to reduce fear and reduce negative rumors, usually in any organization and change team, there are several roles. You have the inventor, the team technical member under a stanza technical aspect of the solution, but rarely knows how to get support around the idea. Next you have the champion. Support the idea, overcome obstacles, obtain the financial and political support. You have the sponsor, a high-level manager that protects the idea and helps remove organization on barriers. You have the critic look for shortcomings and ensures that the idea meets the expectation. Once the team is ready with all four rolls, start by changing people's mindsets around you using training. For example, the idea is to include everyone who has a stake in that change or a stakeholder and start educating them. This will help in improving the quality of the final product as you discover more about the need and it will reduce fear as well. All that he must believe in the project idea. Never allow someone again as a project or you are not 100% sure to become a member of your team. Otherwise, this project will fail from the inside out. The finding that change team is critical for the ERP implementation. They will be the ones responsible for convincing the users to cooperate and gain support for the project. Otherwise, you will be faced with people hiding information during the process mapping phase and which will result in partial implementation of the system way, way too many modification after it goes life. So don't underestimate the need for esteem. Considers this team to be the marketing and the public relation of the project. The ERP implementation is a multimillion dollar investment, dedicating few people to ensure the project success is a low-cost investment, who's a high return investment? So what is the organization development? Organization culture is the personality of the organization. Each organization has a unique culture that emerges from the beliefs and behaviors of its employees. It is difficult to change since it's not something tangible and everyone in the organization contributing to a part of it, however, was the correct demotivation. It can be adjusted bit by bit to move in a different direction. There are three stages of changing mindsets and organizational culture. First, unfreezing. All people throughout the organization are made aware there is a problem and we need to fix it. This can be also in the form of presenting the current estate ends a desired state always highlight the performance gap between the current and the desired performance. Next you move to changing. After people are made aware of the problem, intervene with a new process or technology. In this case will be the AARP and the conductor training for people. Most users need to be aware of the issue to avoid resistance. They need to understand why this is happening. We need to understand why you are changing the way things were. And finally, refreezing. Refreezing happened when users start accepting the new system as the new normal and their attitude change. One of the major blockers in moving from one step to another is resistant to change. And buttons. This one, I have to say a critical warning. Some people were resisted change regardless of what the project is trying to reach. Idea is trying to win as much as possible of this group. In the end, there will be some left who will never support the project. That recommendation in such a situation is to simply move forward. And they will only move to your side once they see the positive impact. So why people resist change? People resist it changes for many reasons. The most common reasons are conflict with self-interest, loss of power, prestige or benefit. Counters this by finding what interests each one and emphasize on it, lack of understanding and trust, the employees often distrust the reason behind any change. What is the intended reason for this change? Counter this point by training and workshops, be inclusive as much as possible and maintaining the status quo. And this case uncertainty. Some people are risk averse by nature and would like to maintain everything as, as this is, can be countered by demonstrating the performance gap and conducting the workshop. And finally, you have different goals. And this is a challenging one. The manager of each department have their own goals directing resources away from the goal of the actual program or a project. This may impact does support for the project, but this could be a deeper indicator of a major problem in the goal setting in the organization. So how to minimize the resistance? There are some tactics to minimize the resistance to change or even overcome IT. Training and communication. Don't try to hide anything and always communicate, reduce fear, because eventually they will know why. So there is no point of hiding it upfront. Participation, involvement and setting the goal would reduce the resistance people need to contribute even with a small, tiny part. Two workshops have an open-door workshops. People can just come in if they are interested to ask a question or even to understand the project. Yes, it will waste a lot of time, but minimizing the resistance is very critical. Negotiation. We talked about this and conflict resolution in the previous part. Coercion, that top-down approach, manager, forcing employees to change to the new system. This also is very effective in the, if you have different goal that causing resistance to the project mural program. Same with the top management support. And the final note, you need to get all of these elements right just to make the ERP system succeed. But the returns of a correct implementation of the system, I would weigh the long road. Because once systems get implemented correctly, you'll get visibility about areas of improvement and maybe even new opportunities to improve the company and position in the market. Thank you for watching and see you in the next course.