Enterprise Architecture

ERP contracts are not as straightforward. Depending upon the engagement structure (and different parties involved), the arrangements could vary, with serious implications on the outcome. These agreements include various elements, such as relationships and obligations of different parties involved, including licensing, pricing, implementation, support, and maintenance. They set the tone for your ERP initiatives.

Misunderstandings start with the misalignment in expectations. Even if different parties claim to be aligned, they might still arise because of the language used. The same keyword could mean different things in different contexts. For example, customers might expect ERP vendors to do the heavy lifting. However, vendors might expect their role to be just advisory due to the limited budget. Even if contracts might include detailed RACI charts, there might still be layers that might cause confusion and disagreements.

Moreover, customers struggle with ERP contracts due to their myopic focus on hourly rates, pricing, and discounts, and because of this, they lose sight of details. The problems with contracts are very similar to any complex project, especially with scheduling. Because customers underestimate the complexity and expertise required to read between the lines. This article will explore the top five types of ERP contracts, discussing their nuances, benefits, and potential drawbacks.

1. Software License, Implementation,  and Support on OEM Papers

In this ERP contract arrangement, you enter into multiple contracts directly with the software OEMs. In the ERP industry, the OEM would be software publishers such as SAP, Oracle, or Microsoft. The software OEMs would not only provide the software and product support, but they would also use their professional services to help with implementation. These contracts are usually segregated into software, service, and support agreements, each serving a distinct purpose and carrying different legal obligations.

The software agreement encompasses an End User Licensing Agreement (EULA), which defines the terms and conditions for utilizing the ERP software and the accompanying IP rights. On the other hand, the services agreement focuses on the services related to implementing the ERP software. This typically includes information about the skills required, the methodology for implementing the software, project timelines, and the roles and responsibilities of both parties involved.

The support agreement specifies the support services provided for the ERP system. It often categorizes support into different tiers based on the severity of issues, sets timelines for issue resolution, and may define billing rates for additional services not covered by the initial support agreement. This agreement may also contain provisions related to warranties.

Key points to remember: OEMs are generally cautious in their consulting and support recommendations. The caution arises because any help or recommendations they provide in areas not explicitly defined in the contract may affect their obligations under the software agreement. By assuming too much risk in these areas, the software company may potentially jeopardize its software contract so they may be conservative in their approach.

2. Software Licenses on OEM Papers; Engagement with a Reseller

In this arrangement, the software contract is still with an OEM, but your primary engagement will likely be with a reseller. These resellers typically have access to the OEM’s quoting software and can provide a quote on official OEM documents.

In this arrangement, the OEM works in the background. They may not actively engage with the customer unless specific issues arise that may require their involvement, particularly if the customer’s relationship with the reseller becomes problematic. In such cases, the OEMs generally take over the reseller and might suggest switching to another reseller. In this arrangement, there are potential issues to consider:

• Discounts and Costs: The discounts and costs associated with the ERP software may change based on new resellers’ tier status. 
• Reseller Commissions: Switching to a different reseller might affect the commission structure, potentially leading to a loss of existing discounts or benefits.
• Support Costs: If the company decides to switch back to the OEM for support, this may be more expensive than receiving support from the reseller.

Key points to remember: The support for the ERP software in this arrangement can vary. Sometimes, the software OEM may still provide support directly, or the reseller might handle the first level of support. The reseller will collaborate with the OEM if more advanced support is required. Implementation contracts with resellers are usually easier to switch unless the reseller has used proprietary intellectual property (IP) in the implementation. In such cases, changing resellers can be more challenging, as the new reseller or the OEM may not possess the specific industry-specific IP needed for the system to be useful for the customer.

3. Software Licenses on Reseller’s Papers 

In this arrangement, the software vendor (OEM) transfers the legal responsibility for the software to the reseller. This means that the reseller becomes primarily accountable for the software sales, support, and any legal issues that may arise. The relationship between the OEM and the reseller remains transactional, meaning the OEM would still transact with the reseller for each transaction rather than buying in bulk. The reseller earns a commission for each sale it makes. 

However, the OEM does not control (at least not directly) the final selling price the reseller offers to customers. The OEM provides the software to resellers at a wholesale price. This wholesale price is typically lower than what end customers pay. In this arrangement, the reseller can determine the final selling price to customers. 

Key points to remember: The legal responsibility for the software product is entirely shifted to the reseller. In other words, if any legal issues or disputes arise related to the software, the reseller is held accountable. The reseller is also responsible for providing customer support for the software. Customers may contact the reseller for assistance, and the reseller is expected to resolve any issues. Additionally, the reseller may be able to customize the software to meet industry-specific needs.  It’s common for resellers in this arrangement, especially those dealing with horizontal software platforms such as SAP, Oracle, NetSuite, or Microsoft, to have their own Intellectual Property (IP) that enhances the core software. This IP may provide industry-specific functionalities that cater to the unique needs of specific business sectors or verticals.

4. Software Licenses Sold in an OEM Relationship by Software OEMs

This is a special arrangement with resellers and might be reserved only for certain territories/geographies or for very large resellers. In this arrangement, the resellers acquire licenses from their software publishers (or software OEMs) in an OEM arrangement. This agreement might be based on a volume purchase, which means the reseller commits to buying a large number of software licenses. 

In this scenario, the reseller could substantially change the software’s code, including selling under a completely new brand in a white-label arrangement. This can include customizing the software to meet specific needs, adding new features, or altering the software’s appearance. 

Key points to remember: In this situation, the reseller OEM primarily acts as the software platform provider. They focus on creating and maintaining the core software product. You might have limited or no direct interaction with the software OEM as a customer. Instead, your dealings would be mainly with the reseller OEM. Since you’re primarily dealing with the reseller OEM, you may not have access to the software OEM’s support and resources. If you encounter issues or need assistance, you typically contact the reseller OEM. If the reseller chooses to white-label the software, they may establish support and implementation services. This means they’ll provide customer support and help with the software’s deployment independently of the software OEM. They might have their dedicated support team and resources to assist you.

5. Software Licenses Sold in a Master Distributor Relationship

In this arrangement, the software OEMs may have several layers of master distributors with their respective channels to distribute the licenses. This arrangement is similar to the reseller OEM relationship in #4, where the software OEM will likely be least involved with the licensing and support. And for the most part, you are likely to deal with a master distributor. 

Key points to remember: This arrangement is especially common with companies selling hardware, but software vendors like Microsoft will likely have similar relationships even for their ERP channel. Due to the nesting of relationships and contractual dependencies, this is perhaps the most convoluted arrangement where understanding the roles and responsibilities of each party might be harder, even for ERP experts.

Conclusion

Understanding the legal obligations of each party involved is essential for the project’s success. Otherwise, get ready to face the financial and legal surprises. These relationships and arrangements can challenge even the professionals tracking the space daily. So, don’t underestimate the expertise required to understand these contracts. Hire the advisors at least for negotiation before creating a million-dollar disaster by not fully understanding what you are signing up for.

FAQs

The list of ERP business processes is endless and can seem overwhelming. However, not all these processes hold equal importance and can vary significantly depending on their interaction with the ERP system. While core processes tend to be consistent across most solutions, non-core ERP business processes vary considerably.

Various factors influence whether a business process qualifies as core or non-core. Typically, core processes are hosted within the ERP system, while non-core ERP business processes may often reside in external systems. For instance, the order-to-cash process is a classic example of a core ERP cross-function business process commonly integrated into the ERP system. Other processes like Dispatch-to-deliver and Issue-to-resolution demonstrate high levels of integration with ERP systems but may vary based on business models.

Cross-functional business processes can also undergo significant transformations depending on the industry they serve. For instance, the order-to-cash process for a manufacturing company can differ substantially from that of a transportation company, with the latter possibly residing in a Transportation Management System (TMS) rather than the ERP. Understanding these non-core ERP business processes is essential for making informed decisions about system selection and architecture, as the line between integrating them into the ERP or opting for a best-of-breed solution can be quite thin.

1. Dispatch-to-deliver

The dispatch-to-deliver business process initiates when a shipment is ready to dispatch from the facility. It involves several steps, like planning and coordinating various stages in the supply chain. It is to ultimately deliver goods to the customer and obtain their signature as proof of receipt. This business process primarily falls under the responsibility of the supply chain execution function. 

Typically, ERP systems do not include the dispatch-to-deliver process as an integral part of their functionalities. Instead, specialized systems like WMS(Warehouse Management System) or TMS(Transportation Management System) generally facilitate this process.

However, some systems available in the market offer an embedded experience for the entire dispatch-to-deliver process. Therefore, when deciding how to manage the dispatch-to-deliver process within your organization, you should consider transaction volume and architectural requirements. Depending on your specific needs, you can incorporate this process within your ERP system or introduce a dedicated WMS or TMS system into your architecture.

2. Hire-to-retire

The HR department primarily manages the hire-to-retire process. It begins with the recruitment of candidates, their onboarding, training, and monitoring of their job performance, and concludes with the necessary procedures when the company either terminates them or they leave voluntarily. 

In most cases, an HCM system facilitates this process. Generally, ERP systems do not have the functionality to host this process. However, there are instances when the hire-to-retire process interacts with ERP systems in industries where specific skills and certifications are integral to the operational processes. 

In such cases, ERP systems tailored for these industries may incorporate certain elements of the hire-to-retire process. This integration ensures that HR-related data, like employee skills and certifications, is seamlessly integrated into the broader ERP system, enabling better workforce management within the company’s overall operations.

3. Issue-to-resolution

The issue-to-resolution process is a fundamental customer service procedure that companies follow to address customer concerns and ensure the smooth functioning of their products or services. It typically commences when customers reach out with specific issues related to their equipment or services. Upon receiving the customer’s call or inquiry, service teams assess whether the equipment or service is still under warranty coverage as the first step. This can significantly impact the resolution process.

If the warranty covers the equipment or service, the service team provides the necessary services to rectify the issue. In cases where the warranty has expired or does not apply, the service team may initiate the process of issuing a purchase order for any required replacement parts or services. This process may sometimes involve physical visits to the customer’s location, especially if there is a need for on-site repairs or inspections.

Managing this process is essential for customer satisfaction and operational effectiveness for companies. They often host this process inside CRM or a best-of-breed field service system. Depending on their specific needs and preferences, some companies integrate this process with their ERP systems, initiating the flow with a service order or a GL entry. 

4. Lead-to-quote

The lead-to-quote process is integral to pre-sales and marketing automation workflows, primarily hosted within CRM systems. It commences by creating leads, which are potential customers, through various channels such as physical marketing campaigns or digital initiatives. 

These leads then move through the funnel using a series of interactions, which involves estimating the required services, if necessary, engaging in engineering activities to tailor offerings to the customer’s needs, and, finally, releasing the quote. 

It’s important to note that in most cases, this process remains within the confines of the CRM system and does not typically involve an ERP system. However, exceptions exist, particularly when engineering processes require access to product data or when configuring complex product quotations (CPQ), necessitating a connection to the ERP system.

5. Campaign-to-lead

The campaign-to-lead process is a fundamental aspect of marketing and sales operations within a business. It is a crucial precursor to the lead-to-quote process or can function as a subset. 

This process begins with the initial design of marketing campaigns, which can be either physical, such as print advertisements or billboards, or digital, including online ads and social media promotions. After campaign planning, the next step involves executing these marketing initiatives. Subsequently, it necessitates the measurement of campaign results to gauge their effectiveness.

A key component of the campaign-to-lead process is capturing potential customers’ interest and guiding them through the sales funnel until they convert into leads. It’s important to note that, in most cases, this process operates independently of the company’s ERP system. ERP systems typically come into play much later in the customer journey, mainly when leads are qualified and have the potential to translate into financial opportunities for the company.

6. Contract-to-enroll

Companies involved in multiple enrollment campaigns commonly use the contact-to-enroll business process, particularly for subscription-based services like educational courses or paid events. This process guides potential participants from initial contact to successful enrollment.

It begins with identifying specific programs or offerings the organization wants to promote. Once they identify the programs, the next step involves crafting targeted marketing campaigns to generate interest among potential participants. The process also involves nurturing these prospects through a sales or enrollment funnel. This may include various stages, such as providing information, addressing queries, and guiding them to the enrollment step. 

These programs may be paid or unpaid depending on the organization’s objectives. It’s important to note that unless there is a specific requirement for integrating financial aspects into the organization’s ERP system, this contact-to-enroll process typically operates independently from the ERP, focusing solely on the enrollment journey of potential participants.

7. Expense-to-pay

Expense-to-pay is a crucial component within an organization’s time and expense workflow. In this process, an employee initiates the workflow by reporting expenses incurred during client visits, projects, or events. These expenses may include a wide range of items, such as travel costs, accommodation, meals, and other related expenditures. 

The primary goal is to accurately document, validate, and eventually pay or bill these expenses, depending on the specific circumstances. Depending on company policies, some expenses may need to be billed to clients for reimbursement, while others may be eligible for direct reimbursement to the employee. Additionally, organizations often need to oversee and control budgets associated with employee expenses, ensuring that expenditures remain within predefined limits. 

Employees who have received company credit cards to facilitate expense transactions manage these cards, including monitoring transactions and ensuring timely payments. Companies may host this complex process within a specialized T&E software or utilize the T&E module within their ERP system.

8. Recruit-to-hire

Recruit-to-hire is a fundamental process that lays the foundation for an organization’s workforce. It is a precursor to the hire-to-retire process. First, it all starts with creating job descriptions that outline the roles and responsibilities expected from potential candidates. Once these descriptions are in place, the process shifts towards identifying the most suitable channels for sourcing potential candidates. This could involve posting job listings on websites, utilizing recruitment agencies, or leveraging social networks.

Following candidate sourcing, a critical aspect of recruit-to-hire is conducting evaluations and interviews. This entails assessing candidates’ qualifications, skills, and cultural fit within the organization. Organizations often perform background checks to ensure the correctness of a candidate’s claims and protect the company’s interests.

Finally, once a candidate is selected, the recruit-to-hire process culminates with signing offer letters, solidifying the employment agreement. While it rarely touches ERP, companies often use various systems like Applicant Tracking Systems (ATS) or Human Capital Management (HCM) software to streamline and manage these tasks efficiently.

9. Return-to-refund

The return-to-refund process is an integral component of the overall return procedure within a company. This process typically begins with the initiation of a return request by the customer. Once initiated, the company handles various steps, including processing the return, providing appropriate packaging and labels, and receiving the returned inventory. 

They perform a crucial quality check at this stage to ensure the returned items meet the necessary standards. Subsequently, the respective vendors might receive the inventory back, and they may manage the warranty process if applicable. Finally, the company issues the refund to the customer, thus concluding the transaction. 

To host the return-to-refund process, companies commonly integrate software systems, such as eCommerce platforms, POS systems, or ERP software. Moreover, the return process frequently interfaces with other essential systems, including WMS, OMS, and CRM tools. Within an ERP workflow, the process can start by directly capturing the return request within the ERP system or by interacting with it to process the necessary General Ledger (GL) entries.

10. Market-to-order

Market-to-order is a comprehensive business process that serves as a superset of lead-to-quote and the precursor of order-to-cash. The process begins with formulating and maintaining a well-thought-out marketing plan, which includes strategies and tactics to reach the target audience effectively. Once the plan is in place, the next step is the design and execution of marketing campaigns, aligning them with the established budget.

Throughout the marketing campaigns, monitoring their performance and effectiveness is crucial, ensuring that they yield the desired results. As part of this process, leads are generated and captured. Managing these leads involves guiding them through the sales funnel, where they are nurtured and engaged until they reach the point of conversion into actual orders. This conversion marks a critical transition from marketing to the subsequent stages of the business cycle.

In most cases, Market-to-order operates independently of an ERP system. However, in some situations where quoting, estimation, and engineering processes are tightly integrated into the company’s operations, they might be hosted within the ERP system. Alternatively, if the quoting and estimation functions are part of the ERP, the integration may occur even earlier in the business cycle.

Conclusion

In conclusion, distinguishing between the core and non-core ERP business processes is necessary to navigate different business processes smoothly. The nuances of ERP systems and diverse industry requirements often complicate this task. While core processes are consistent and typically integrated within the ERP, non-core processes can exhibit a broader spectrum of possibilities, including integration with best-of-breed solutions or residing in external systems. Recognizing the distinctions and dependencies among these non-core processes is crucial for making informed decisions about system selection and architecture.

FAQs

ERP systems play an important role in streamlining the operations of a business. At the heart of these systems lie the core cross-functional business processes. Also, catering to the needs of different departments, these business processes are like building blocks for the organization to work smoothly. They include sequential activities across different departments to complete a financial or operational workflow. However, unlike ERP modules that you can choose individually, these core tightly integrated business processes rely on each other. In other words, implementing one process also entails addressing its underlying dependencies on other ERP business processes and modules.

Yet, the challenge many businesses face is understanding the significance of these core ERP processes. Without this essential knowledge, companies often encounter operational roadblocks and inefficiencies. Departments might function in isolation, lacking the interconnectedness needed for streamlined operations. This is why understanding these core cross-functional business processes is very important.

In this blog, we will talk about the top 10 core cross-functional business processes that bind different departments together.

1. Order-to-cash

The order-to-cash process is a complex business operation that includes various departments within an organization, such as sales, operations, and finance. From its initiation to the collection of payment, this process involves the entire lifecycle of a customer order. When a customer places an order, the process begins. Sales teams are responsible for capturing the order details, including product or service specifications, quantity, pricing, and customer information. 

Upon capturing an order and validating it, it moves to the operations department for processing. Operations personnel check inventory levels, product availability, and service delivery schedules if applicable. To fulfill the customer’s requirements, they also create picking lists, work orders, or service orders. This step in some industries, such as manufacturing or service-based businesses, ensures that the products or services meet the order specifications. After order fulfillment, the finance department generates an invoice based on the order details. Upon issuing the invoice, the finance team tracks and manages payments from the customer. 

Depending on the organization’s architectural boundaries, some companies host this process on one or multiple. Sometimes, the boundary of an ERP system may start from an invoice or GL. In other cases, the whole process happens within the ERP system. Therefore, when you choose an ERP system, define how much order-to-cash you would host inside the ERP. This will also help you find the right ERP system aligned with your business needs. 

2. Procure-to-pay

Managed within an ERP system, the procure-to-pay process is among significant cross-functional ERP business processes. Generally, this process encompasses several stages and involves different departments within an organization, including procurement, warehouse management, finance, and accounting. The process begins with the procurement department capturing a purchase order. 

Upon capturing the purchase order, the warehouse receives the inventory. After this, the finance department receives the vendor’s invoice, which includes the billing details for the delivered goods or services. Then, they would match an invoice against the corresponding purchase order and receipt information in the ERP system to ensure accuracy. The finance department initiates the payment process after the invoice is verified and approved. 

The degree of integration with the P2P process into a single ERP system can vary among organizations. Some may handle the entire process within the ERP, starting from the purchase order, while others might use additional specialized systems for certain steps, like procurement software for purchase order management.

3. Plan-to-produce/Plan-to-inventory

The plan-to-produce/plan-to-inventory business process is particularly relevant for industries that require accurate forecasting and planning of inventory before production. Commonly seen in consumer-centric and commoditized industries, the process begins with S&OP analyzing historical sales data, market trends, customer demand, and other relevant factors to forecast the demand for their products. 

After forecasting demand, the next step is supply planning. In this phase, companies determine how they will meet the anticipated demand. It involves assessing the available resources, production capacity, and procurement capabilities. Once the supply plan is in place, the procurement department comes into play. Their role is to source the necessary materials, components, and resources required for production. This might involve negotiating with suppliers, placing orders, and managing the procurement process efficiently to ensure that materials are available when needed for production. With the materials procured and the supply plan in hand, the production and manufacturing teams swing into action. To produce the goods in line with the forecasted demand, they use the production schedule generated during supply planning. 

Some companies might host the entire P2P process within their ERP system. In such cases, the ERP system handles everything from forecasting and planning to procurement and inventory management. However, others may use a separate S&OP system for initial demand forecasting and supply planning. In the latter case, the S&OP system feeds planned forecasts and supply plans into the ERP system to execute the production and inventory management processes.

4. Record-to-report

Primarily managed by the finance department within an organization, the record-to-report process is a critical business process. Its main purpose is to handle non-operational transactions accurately. In many organizations, ERP systems play a central role in managing financial data. However, ERPs may not offer automated recording of all financial transactions as some are non-operational and might require manual recording. The process begins with the finance department recording financial transactions. 

After recording transactions, finance professionals reconcile accounts. This step is crucial for ensuring that the recorded data is accurate and that there are no discrepancies or errors. Reconciliation involves comparing various financial records and ensuring they match. While the core of the record-to-report process resides within the finance department, it might require multiple systems to manage it. For example, they might use the ERP system to capture and initial transaction reconciliation. Still, they may transfer GL data to a separate FP&A software system. Before generating final financial reports, finance teams might sometimes consolidate data in the FP&A software. This step is essential for producing accurate reports, especially for larger organizations with multiple subsidiaries or divisions. 

The ultimate goal of the record-to-report process is to create financial reports. These reports provide a snapshot of an organization’s financial health and performance over a specific period, such as a month, quarter, or year. Before finalizing and distributing financial reports, finance professionals often analyze the data to identify trends, anomalies, and insights. The record-to-report process also plays a significant role in ensuring compliance with financial regulations and standards. Organizations may be subject to internal and external audits to verify the accuracy and legality of their financial statements.

5. Source-to-pay

The source-to-pay business process is one of the workflows within an ERP system that encompasses activities related to sourcing and procurement. Organizations follow a series of steps to effectively manage their procurement cycle, from identifying and building consensus on the need to identifying qualified vendors and finalizing payments. The process usually starts with identifying the organization’s need for certain goods or services.  

Post that, it often requires consensus-building within the organization among various stakeholders. This step ensures the procurement aligns with the organization’s goals and budgets. After obtaining internal consensus, the next step is to identify potential vendors or suppliers who can fulfill the requirements. Upon identifying potential vendors, the organization conducts a thorough vetting process to assess their capabilities, financial stability, and adherence to legal and ethical standards. This step helps in ensuring that selected vendors are trustworthy and capable. After vetting the vendors, the organization awards a contract to the selected vendor(s). This contract outlines the terms and conditions of the procurement, including pricing, delivery schedules, and quality standards. This step formalizes the relationship between the organization and the vendor. 

With the contract in place, the process proceeds with all the steps of the P2P process. Depending on the complexity of the sourcing phase, there might be several systems, and the ERP flow might start with a purchase order. The other companies might host RFQ comparisons, etc., inside the ERP.

6. Idea-to-Offering

The idea-to-offering business process is essential to new product development within a company. This process involves multiple stages and activities, from marketing to operations, figuring out go-to-market fit before a product is ready for production. The process starts with extensive market research and analysis to understand the potential demand for the product. This includes studying customer needs, preferences, and market trends to refine the concept and make it more customer-centric. 

After gaining insights from customer research, the company begins the engineering phase. This involves designing and developing prototypes or mock-ups of the product to test its feasibility and functionality. In parallel with engineering, the company starts the procurement process. This involves sourcing the necessary materials, components, and resources for the product. Procurement also includes negotiations with suppliers for pricing and terms. The company works closely with its suppliers and partners during the design and sampling phase to ensure efficient manufacturing of products and meet quality standards. Simultaneously, the operations team strategizes the go-to-market plan. This involves deciding on pricing, distribution channels, marketing campaigns, and other factors essential for successfully launching the product. 

At this point, some companies may host this process in different systems. For instance, They might use a PLM system for program and idea management, CAD/PDM tools for engineering, and P2P systems for vendor collaboration. When all preparations are in place, the ERP system takes over. With the product now in the ERP system, production can begin. Some companies may host the entire idea-to-offering process within their ERP system, consolidating all stages and data into a single integrated platform for more streamlined management and control. 

7. Count-to-reconcile

The count-to-reconcile among ERP business processes is an integral part of managing inventory within an ERP system if it is the main source of truth for inventory. It’s a systematic procedure that usually begins with the planning phase for inventory reconciliation. This involves deciding how often inventory counts will occur (e.g., daily, weekly, monthly) and which inventory items, warehouses, or locations will be included in the counting process. To prioritize inventory counting efforts, items are often categorized into different classes based on their value, criticality, or other relevant factors. The ABC classification system typically consists of: A-Class: High-value or critical items, B-Class: Moderately valuable items, and C-Class: Low-value or less critical items. 

Once the items are categorized, specific items, warehouses, or locations are identified for counting based on the inventory reconciliation plan. A pick list is generated to guide the counting process. Depending on the organization’s technology and preferences, the counting can be done using handheld devices. Discrepancies between the physical count and the ERP records are inevitable. If found, adjustments are made. Once all items have been counted, adjustments are posted. It reconciles any discrepancies identified during the counting process. 

Depending on the organization’s technology landscape, inventory and location information might be stored in various systems like WMS, eCommerce platforms, or OMS. In many cases, the ERP system is the central source of truth for inventory management. This means that all inventory-related information and adjustments are primarily handled within the ERP. Therefore, the Count-to-Reconcile process plays a critical role in maintaining the accuracy of inventory data within the ERP system.

8. Forecast-to-monitor

The forecast-to-monitor business process plays a significant role in the budgeting and financial management of an organization. It involves a series of steps designed to ensure that an organization effectively plans, tracks, and manages the budget of each account and department. The process begins with planning various financial scenarios. 

Once done, historical trends for each account are analyzed to create accurate budgets. This involves looking at past financial data, such as revenue growth, cost patterns, and other relevant financial metrics. The key aspect of this business process is collaboration. Teams from various departments within the organization need to work together to develop a comprehensive budget. Each department will have its budgetary requirements and contributions to the overall budget. Collaboration ensures that all stakeholders’ input is considered in the budgeting process. After considering different scenarios, analyzing historical trends, and collaborating with teams, the organization sets its budget for the upcoming year. Once the budget is set, it’s crucial to monitor and manage it throughout the year continuously. 

Depending on the complexity of the budgeting process and the data requirements, organizations may choose to manage this process within their FP&A department or directly inside their ERP system. If they opt to use the ERP, it typically involves entering budgeted numbers into the ERP system to track yearly performance.

9. Inspect-to-comply

The inspect-to-comply business process is part of the quality management process. The workflow usually begins with the creation of a detailed test plan. This plan outlines the specific quality criteria and standards that need to be met for the product or material being tested. It specifies what aspects will be inspected, which tests will be conducted, and the testing methods to be used. 

Once the plan is in place, the next step is to identify the test cases. Test cases are specific scenarios or conditions that are designed to evaluate the quality of the product or material. These test cases are based on the requirements outlined in the test plan. After identifying the test cases, the next step involves identifying and selecting inventory items that need to go through the quality inspection process. Once the inventory items are identified, the next step is to execute the test steps according to the predefined test cases. During the execution of test steps, all relevant data and test results are recorded and documented. In some cases, materials may not meet the quality standards initially. When this happens, a material review process is initiated. 

Finally, the process involves preparing all necessary documentation to ensure compliance with quality standards and regulations. This documentation may include test reports, certificates of compliance, and other records that demonstrate that the items have met the required quality criteria. Depending on the organization’s setup, the quality management processes can be integrated into their ERP system, typically in a dedicated quality module. Alternatively, some organizations may use external quality management software that works in conjunction with their ERP system to handle these ERP business processes efficiently.

10. Cradle-to-grave/Acquire-to-retire

The cradle-to-grave/acquire-to-retire process is a significant approach to managing an organization’s entire lifecycle of assets. This process includes several stages, from the initial acquisition of assets to their eventual retirement. It usually begins with the acquisition of new assets within an organization. During acquisition, the organization typically creates purchase orders, negotiates contracts, and records the financial transactions related to the asset procurement. 

After acquisition, the assets are integrated into the organization’s financial system, often within an ERP system. The financial process among ERP business processes includes recording the asset’s value, computing the depreciation lifecycle, and accounting for related expenses such as maintenance, insurance, or licensing fees. This often leads to the steps of generating reports and retirement of assets. Reporting is crucial to monitor asset performance, maintenance costs, and compliance with accounting standards. As assets reach the end of their useful life or become obsolete, they are retired from active use. 

Depending on the organization’s industry and the complexity of asset management, the entire process may be handled within a single ERP system. Alternatively, some companies may use a combination of systems, with the ERP managing financial aspects and Enterprise Asset Management (EAM) or Manufacturing Execution Systems (MES) handling maintenance and operational aspects.

Conclusion

To summarize, the top 10 core cross-functional ERP business processes are essential components that help organizations operate efficiently. These processes connect different departments of a company and are vital for various tasks, from managing customer orders to handling procurement, forecasting demand, maintaining financial records, sourcing, and developing new products.

Understanding and improving these ERP business processes is not optional; it’s perhaps the first step for organizational integration and finding synergies across departments. These processes align departments in how they will be processing transactions and what will be their roles and responsibilities in facilitating that. Whether fully integrated into ERP systems or supported by other software, these processes are fundamental to improving efficiency and effectiveness in diverse industries.

FAQs

One misunderstanding that is prevalent among business owners is a simplified view of business transformation: choose a technology and implement it. How hard could it be? Well, as long as you know which technology will produce tangible business results. Most importantly, how to get there. But let’s not get too far, as most companies struggle to agree on the definition of ERP. They might not appreciate the value of organizational readiness for ERP implementation.

Let’s look at it from another perspective. Most people talk about ERP implementation failure, but they rarely have a good handle on the root cause. It’s most certainly not what they think it is, as projects fail before they even start. They fail because of the misalignment in the expectations. The misalignment could stem right inside executives’ heads. They might have different expectations from the system, completely off from the ground reality. They might struggle to articulate their thoughts to the extent that they might feel overwhelmed and confused. This is where a well-defined roadmap and blueprint could streamline the thought process and build consensus among teams.

Yet another perspective is related to everyone’s estimation of their own capabilities. Let’s face it. Most of us like to overclaim our capabilities because we have a tendency to figure things out given enough time. Unfortunately, this tendency leads to a snowball effect with the consequences as severe as the ERP project not even being recoverable. Going through the formal processes aligns expectations and removes these barriers, helping them understand why they need to think through their decisions. Organizational readiness is very similar to therapy sessions for the entire team and comprises the following six fundamental components:

1. Strategic and Executive Alignment

The problem starts at the top. Most business transformation initiatives, such as ERP implementation, require business model changes. Unfortunately, these business model changes are not as simple as moving a warehouse from one location to another. Instead, they are like performing heart surgery for the business. The issues are especially challenging as the business model changes would be nearly impossible with the amount of disruption they may cause. For this reason, most executives end up choosing the path of solving them technically just because they can’t visualize the technical implications as well as they do the consequences with physical processes.

Getting everyone on the same page about how the transformation initiative will change the business is significant. It should start with your leadership crafting a goal statement that may include the business value of the transformation initiative and forecasting potential changes required to make the initiative successful. You might want to ask questions such as:

• Does your organization have clear expectations on the outcome of business transformation?
• What objections are you likely to get in making business process and model changes?
• Does the executive team have the necessary skills and experience to be able to foresee financial and technical risks because of these initiatives?
• How is your current compensation structure, and how might that influence political forces among different functions and business units?

Communicating these strategies is a big part of aligning with the organization’s business model. Just like therapy, you need to have different strategies depending upon the needs of each stakeholder, with several tools and workshops tailored to their needs until they internalize the process and feel mentally conditioned to go through such a rigorous routine.

2. Operational Readiness

Mental conditioning is just the start. Operational readiness is like a physical sketch of your entire journey, where you are today and where you are headed. The process starts with getting the mental models on a piece of paper. So they can see where everyone’s heads are. It also requires developing a common language for every term that is likely to throw off the model. It’s almost like developing a language, or their mental state is likely to be far off from the ground reality. 

Once you have the common language built, it’s much easier for everyone to visualize the to-be state and why the changes requested are pivotal for the success of the program. The concept of operational readiness revolves around preparing specific functions and business processes for the change. It aims to answer questions that pinpoint the practical aspects of readiness. You might ask questions such as:

• Does your team understand the current processes? Do they understand it well enough to draw them on a piece of paper?
• Do your stakeholders have different versions of the same process in their heads?
• Which business processes would require re-engineering that would streamline the technical implementation? 
• Can business processes be re-engineered without causing major disruptions to the core operations? 
• How would the changed business processes be rolled out? 

The physical sketches substantiate the mental models and help build consensus on the operational state both today as well as in the future. Bringing technology earlier in the conversations generally leads to biased conversations about technology and stakeholders jumping to conclusions without fully understanding the consequences.

3. Data Readiness

One factor among organizational readiness components often overlooked is data readiness. In general, the role of data in the context of systems is to take a piece of connected information from one step to the next. However, not many people realize how data and ERP work together. The absence of data readiness can drive process over-engineering and, in turn, can lead to system bloatedness. 

There are several reasons why companies delay this step to the point where it’s too late. First, while most business consultants might understand process state, data issues require deep implementation experience. Also, during the selection and strategy phase, it’s much harder to visualize the data hierarchy without access to a system to be able to see and feel the changes. So, the data issues tend to get postponed to the implementation phase. But once the contract is signed and if the data model is too off, it can throw off the entire implementation. The questions you should ask related to data re-engineering are as follows:

• How is your current master data modeled? Have you done any customizations to your processes because of data issues?
• Have you had multiple disconnected instances of master data records in the system?
• Do you have data governance issues where the model does not seem to follow any logical structure?

An information model is very similar to a mental model, with the only exception that this state lives in your system’s head. If you overcomplicate the way you register information or don’t simplify, your system might not only experience “brain farts, ” but it might overcomplicate everything else that touches it.

4. People Readiness

Wherever there are people, there will be problems. Several factors drive people-related issues. It could be behaviors influenced by your current compensation structure or power struggle. These behaviors lead to “passive-aggressive” responses to issues without being explicit about them. People readiness among organizational readiness components requires a deep understanding of current behaviors and how that may impact their willingness to change business models or business processes critical for the success of business transformation initiatives. This can be even more challenging if the teams don’t have the right skills. Even small data and process changes might require corporate alignment and intervention from influential stakeholders. 

The biggest challenge with these initiatives is that they are harder to visualize, with the implications challenging to internalize unless you’ve been through these cycles multiple times before. Most people find it easier to trust complex concepts that they’ve seen work firsthand. The questions around people readiness you should be asking are as follows:

• Are you currently experiencing a power struggle in the organization, and if so, do you deeply understand what may be influencing that?
• What does decision-making feel like for cross-functional issues? Do you feel tension with conversations and that people are not willing to open up for underlying issues?
• Do you feel that specific executives have a need for control and that other executives might not open up as easily when they might be around?

People issues are very similar to a board of a company. And unless you have a team that works together really well and trusts others around them to be able to share their feelings, you might require help with people readiness before you undertake your business transformation initiatives. 

5. Technical Readiness

While businesses overemphasize the importance of business and process re-engineering, technical readiness is just as important. It’s an alignment of business users’ and technical teams’ mental models. Both of these teams care for different things, and their heads are wired differently. So, this alignment is even more critical. The technical teams must understand the business vision and must be involved in making critical implementation and change decisions. With them running in trenches, they can see potential financial and technical risks that businesses might ignore. They might code and configure things not aligned with the business vision. 

Most companies take exactly the opposite approach with technical teams. They don’t involve them during the decision-making process, and then when things go south, they are the first ones to get blamed. Technical issues will always require business model changes, and if their voices are not incorporated in the decision-making, there will always be issues, especially if the business teams have a limited technical background. Also, even business executives who might claim to be technical experts rely on technical teams to make decisions for them. Here are the questions you should ask related to technical readiness:

• How are your technical teams? Do they seem to overstate their capabilities? 
• Do they seem to always solve problems through programming?
• Do you have any proprietary systems? How about documented architecture along with process and information models?
• Do you have access to enterprise-wide master data governance and reconciliation flows?

To guide this process, having a detailed technical plan is very helpful. This plan helps the technical teams code and configure things aligned with the business vision. 

6. Project Governance and Planning

After you have the state of your initiatives defined from all perspectives, the next step is to plan how to execute them. System integrators and OEMs generally expect their clients to do 90% of the heavy lifting. There are several factors that drive this behavior. First, the client has unreasonable expectations but limited budgets. So, they leave vendors with no choice but to commit only to a fraction of the work. Second, their software might get blamed because of their involvement or recommendations with data or processes. Finally, the OEMs mandate prescriptive methodologies to their clients and resellers. Equally challenging is managing schedules with ERP projects because of the unavailability of key resources, especially part-time ones.

Project planning involves more than just digital processes. It also means figuring out how physical processes will change and how you’ll communicate these changes to everyone inside and outside your organization. This plan should include a roll-out strategy for introducing these changes in a way that makes sense technically and financially. It should also have KPIs that can help you stay on track. 

It’s not just about making schedules; it’s about organizing resources, communicating well, and ensuring your plan matches what’s happening. As you get ready for this big change, remember that careful planning and smart management are the keys to making your ERP system work well for you.

Conclusion

Each of these perspectives is equally critical. They’re like puzzle pieces that fit together to create a complete picture. Giving too much importance to the technology part and ignoring the people and process parts can cause problems. The technology might not work well with how your team works, making it hard for them to use it properly.

On the other hand, if you don’t pay enough attention to the technical side, you might face technical issues, and the system might not work as it should. Neglecting the organizational readiness and cultural side can result in resistance to changes and difficulty managing the transition.

Success comes from finding the right balance between these different viewpoints. Remember that all six components are important when assessing organizational readiness for ERP implementation. By understanding and considering each part properly, you’ll be on the right track to making your ERP project successful.

FAQs

The list of ERP modules is endless. To an extent that they might come across as overwhelming. But not each module is as critical. Also, each ERP, depending on its positioning, might have different modules. While core modules are likely to be the same across the majority of the ERP solutions, the non-core modules differ substantially. However, there are some non-core ERP modules that are more important than others.

Also, several factors drive whether a module will be a core module or not. One factor is the dataset’s nature and confidentiality. The factors also include: Can an operation be managed in a siloed fashion? Or would it require collaboration with other departments? Let’s compare payroll and recruiting modules. The recruiting module may not have as much dependency on the financial datasets as payroll. So, the recruiting module may not belong to an ERP, but payroll might, despite not being a core module.

The other factors, equally influential, would be the unique functionality required for certain industries. Let’s talk about the subscription-based business model. Not every business or industry is likely to have this business model. But when prevalent, it’s likely to have significant dependency on financial datasets. This model may require periodic billing and may be dependent upon other master data elements that generally reside in an ERP. Unlike core ERP modules, the non-core might be even more confusing as there is a very thin line between hosting them inside an ERP or within a best-of-breed solution. Understanding these non-core modules will help you find the right modules and their appropriate places in the architecture.

1. Human Resources Module 

The only reason why HR functionality exists in the ERP is to allocate labor costs. Allocated for the jobs or maybe to capture the expenses to be able to bill them to the clients. The other HR-specific datasets and workflows, like recruitment, training, program management, new employees onboarding, certifications management, and payroll handling, are generally not part of the ERP. They are not included unless the HR processes need to be part of the operational workflows. 

In some industries where the skillet or training may be a factor in job or resource scheduling, the HR module of ERP might have more advanced capabilities embedded with the operational workflows. It’s also very common in human resources-heavy organizations such as public sector or non-profit. Automotive might be another outlier among manufacturing industries where skill-based processes play a much greater role in resource scheduling. And because of this, they also require human resources to be tightly integrated with the ERP.

Also, in general, there is a huge misunderstanding about HR capabilities assumed to be part of an ERP system. For these reasons, human resources management is generally not the core module of the ERP. If you are new to ERP, don’t focus too much on the HR module, as if you do so, you are likely to miss other features and modules that are likely to break your implementation.

2. Payroll Module

Just like the HR module, ERP systems don’t generally include payroll capabilities. However, there are instances where they might include them, particularly when payroll is a part of their core operations. They might also include them when there’s a need for union reporting that involves data collected from those core operations. This is also a noticeable trend in service-oriented sectors like nonprofits, where grant reporting needs to be correlated and embedded with HR data. Sometimes, they might need payroll data for minority-owned or women-owned certifications. A reporting mandated by their donors and funders. 

Some ERP systems might claim to have payroll capabilities but are generally limited to a few geographic locations. Expecting to acquire as many capabilities as possible for your investment, you might buy an ERP system with payroll capabilities. Only to be disappointed later and switch to another payroll solution if the included module is too clunky or falls short of your needs.

There might also be cases where the payroll capabilities included as part of an ERP might be a white-labeled solution. The vendor might not reveal that you are buying someone else’s offering as they don’t need to be expressive about them. Your decision is likely to be skewed without gaining much with a white-labeled solution. That’s why payroll is not a core module offered with an ERP. So, don’t focus too much on the payroll capabilities with your ERP unless the payroll capabilities are absolutely essential and must be embedded for grant or union reporting.

3. Time and Expense Module

The Time and Expense (T&E) module focuses on managing employee expenses and ensuring their accurate reimbursement. It might also allow you to bill these expenses to the client or clock into a job. Unlike HR and payroll data, T&E expenses are part of the operations, and for this reason, most ERP systems generally incorporate this module. As the number of employees increases, the T&E operations may drive substantial admin costs. So, including a T&E module is generally a wise choice with an ERP.

Within the T&E module, you might discover additional handy features. For instance, it could provide an employee self-service portal or a mobile interface. These tools make it easy for employees to submit their expenses and assign appropriate codes automatically. This streamlined process can save time and reduce errors. 

However, consider a specialized T&E software like Concur if your needs go beyond the basics. This kind of software steps up the game with more advanced capabilities. It can also manage credit cards, ensuring expenses are properly allocated to the right accounts. It can even automate budget management for each credit card issued per department and employee, including managing the credit card reconciliation process. While important, it’s not the end of the world if you can’t use a T&E module as part of the ERP, as generally, it can remain siloed without disrupting operational processes. 

4. Enterprise Asset Management Module

The purpose of Enterprise Asset Management (EAM) is to effectively manage assets throughout their lifecycle. Covering tasks like upkeep, scheduling, preventive maintenance, and financial management. It’s especially critical for asset-heavy industries. These assets could range from machinery and equipment to facilities and vehicles. 

The nature of the assets, whether managed internally or on behalf of clients, determines the specific requirements for asset management. For instance, a company operating a fleet of vehicles might need to keep track of maintenance schedules and repairs to ensure optimal performance and safety. Different industries might have varying needs when it comes to EAM. An ERP system tailored for manufacturing might offer features that help track machine maintenance and production line efficiency. In contrast, an ERP system for real estate might focus on managing property maintenance and lease agreements. 

Certain features of EAM could overlap with other software systems, such as Manufacturing Execution Systems (MES) or field service software. For instance, features related to tracking asset performance and maintenance schedules might also be covered by MES, especially in manufacturing industries where machinery uptime is crucial. Include the EAM module with your ERP if you are an asset-heavy organization. 

5. Lease/Rental Management Module

For businesses engaged in leasing or incorporating leases into their operations, having effective lease management within an ERP system becomes crucial. Lease or rental management functionalities encompass a range of tasks essential for handling leased equipment or assets seamlessly. This workflow entails contract management, dispatch coordination, scheduling arrangements, inspections, repairs, and overseeing financial aspects from both the perspective of the lessor and lessee. 

By integrating lease management into their ERP, companies can maintain a centralized hub for all lease-related activities, streamlining processes, reducing manual errors, and ensuring lease terms and obligations compliance. 

From the initial contract setup to monitoring ongoing operations, this module allows businesses to keep track of lease terms, monitor the condition of leased items, and effectively plan maintenance or repairs. Moreover, financial management capabilities enable accurate tracking of payments, revenue recognition, and expense allocations associated with leases. Include a leasing module with your ERP if your business model includes leases.

6. Subscription Management Module

The subscription management module is critical for businesses that might have subscription-centric offerings as part of their business model. Without this module, these offerings would drive substantial admin overhead for companies as their operational workflows are not as easy to automate with vanilla ERP offerings. This can encompass a range of tasks, such as contract management for subscription services, overseeing different subscription plans on offer, keeping track of how customers use these services, and taking care of the billing process. 

Administration of these subscription offerings would be other capabilities that are generally included as part of this package. This could involve handling different tiers of subscription plans, managing upgrades or downgrades, and handling any changes or modifications requested by the customers. Billing is another critical component of subscription management.

An ERP with subscription management capabilities can automate billing, ensuring accurate and timely invoicing. This level of automation reduces manual errors, speeds up the billing cycle, and ensures that customers are billed correctly based on their subscription usage. However, not all ERP systems designed for subscription-based business models might cover every aspect of subscription management. There could be industries where companies offer subscription-based services but also provide physical hardware or software equipment as part of the subscription package. Specialized capabilities like integration with data center equipment or IoT devices might be necessary in such cases. While not critical for every industry, include a subscription management module if your business model includes subscription-based offerings as of today or plans to launch in the future.

7. Environment, Health, and Safety Module

This module focuses on managing EHS capabilities such as incident reporting, EHS workflow management, and compliance reporting. However, the exact features and scope of the EHS module can vary depending on the specific ERP system’s design and size. Compliance-centric industries, like those dealing with hazardous materials or intricate safety protocols, find this module especially useful. 

On the other hand, businesses where EHS is not as central to their operations might opt for a separate EHS software rather than having this module in their ERP system. Because of the limited operational embeddedness required, siloed EHS software isn’t as bad. Include the EHS module of the ERP, but don’t select an ERP solely because it contains an EHS module.

8. The Governance, Risk, and Compliance (GRC) Module

The Governance, Risk, and Compliance (GRC) module is a crucial part of ERP systems. It covers important areas like audit and risk management and compliance workflows like Sarbanes-Oxley. However, the specific features of the GRC module can vary based on the design of the ERP solution. ERP solutions tailored for regulated industries like banking or finance often have more comprehensive risk management features. 

On the other hand, solutions targeting industries where compliance, certification, or audit are vital might emphasize deeper compliance capabilities. Moreover, the extent of GRC functionalities could differ based on whether the ERP system is meant for public or private companies. Include a GRC module with your ERP if your business model requires GRC workflows.

9. Budgeting and Financial Reporting Module

The Budgeting and Financial Reporting module of an ERP system might include capabilities such as maintaining budget templates, preparing budgets, managing budget workflows, facilitating budgetary and planning cycles, and what-if scenarios. ERP capabilities are generally not as friendly for the budget processes because of the rigidness of the data model and the impact on the operational disruptions due to the inclusion of budgetary dimension. 

However, there are some ERP systems that include FP&A as a separate datastore as part of their bundle, along with the budgeting capabilities embedded with the ERP product. These companies acquired the FP&A solution and integrated it as part of the suite. So, they provide similar capabilities as an external FP&A solution would – with the benefit of it being pre-integrated with the ERP suite. 

The reason why FP&A and CPM processes require specialized software as they often need external and historical datasets, which are much easier to load in an external FP&A software than in an ERP because of the data rigidity of the ERP system. When considering this module, keep in mind that if your business requires detailed budgeting with lots of outside data, you might need to explore other solutions beyond what the ERP system offers.

10. Sales and Operations Planning Module

This module forecasts demand per SKU, product group, or location. It also looks after forecasting the capacity and supply required to meet those demands. However, the sales and operations planning (S &OP) feature offered by an ERP module might have limitations similar to the FP&A solution. That is, loading external and historical data critical to S&OP processes is not as friendly. It also involves collaboration with everyone involved in your supply chain, upstream or downstream.

If your business relies heavily on supply chain planning, you might find that the S&OP module in your ERP isn’t enough. You might require more advanced S&OP software. This would allow you to effectively overlay external data sources and historical information and facilitate better collaboration across your entire supply chain network.

With so many modules packaged with ERP systems, just covering non-core is perhaps not enough. There are some more modules, and while they could not make a cut in the top 10, they might be equally critical for certain companies. While they may have limited applications compared to the core ERP modules, their targeted capabilities can significantly enhance efficiency and effectiveness in the areas they are designed to address. Let’s quickly glimpse these lesser-known yet valuable ERP modules and consider how they might align with your specific business requirements.

1. E-commerce, POS, Customer, and Vendor Portals

Certain ERP systems provide vendor and customer portals that facilitate collaboration between vendors and customers. Some also include a module for handling cash sales through a Point of Sale (POS) system. Additionally, a few ERP systems market their customer portals as eCommerce portals. But for the most part, ERP systems’ eCommerce and POS capabilities are relatively limited. If a significant portion of your revenue is generated from online or retail sales, the eCommerce and POS features within an ERP module could be limited due to minimal payment integration choices and a lack of search engine-friendly technology.

2. Supplier Relationship Management

This module handles supplier interactions, sourcing, relationship management workflow, RFP and RFQ management, vendor scorecards, and contract lifecycle management. Its depth can vary based on ERP design and industry focus.

3. Cash and Treasury Management

This module centralizes cash management, including administration, cash forecasting, workflows of treasury professionals, and cash risk management. Larger ERP systems for public companies have advanced capabilities, while mid-market systems often offer basic functions.

4. Last Mile and Proof of Delivery Module

Smaller ERP systems in industries like food, pharma, and field service may include capabilities that are generally found in a TMS system, like the entire workflow for dispatch-to-deliver, including picking and packing workflows of the in-house fleet, scheduling of deliveries based on zip code, route accounting, and proof of delivery. Larger ERPs might need add-ons for these specific capabilities.

5. Engineering Management Module

Suited for engineering-focused organizations, this module includes new product development, engineering change control, product and program management, R&D, vendor collaboration, and CAD integration. Smaller ERPs may have comprehensive engineering features, while diverse systems might rely on PLM/PDM solutions.

6. Construction Management Module

Useful for construction-heavy organizations, this module assists in project management, submittals, stakeholder coordination, and specialized construction needs.

7. Non-profit Management Module

A specialized accounting module for non-profits, it handles fund-based reporting, program management, donations, campaigns, and volunteer management.

8. Enterprise Document Management Module

This module handles controlled access, storage, version control, and regulatory workflows for documents. Most ERPs include native or integrated documentation management.

9. iPaaS/EDI Integration Module

ERP systems include integration layers for automated communication with external systems, supporting EDI and non-EDI interfaces. Some might use third-party iPaaS tools for integration.

10. Business Process Management (BPM) Module

This no-code platform enables workflow creation, approval flows, master data governance flows, and building additional validations on top of the core ERP layer. ERP systems might use the same platform for customer customization.

Conclusion 

In conclusion, while core ERP modules lay the foundation for businesses, non-core ERP modules offer targeted functionalities that cater to specific industries and unique business processes. Though not as widely known, these modules hold immense value for organizations seeking to optimize their operations.

As you start the ERP journey, understanding how these non-core ERP modules differ is important while continuing the ERP selection process. While reviewing different ERP systems, these modules will likely appear very similar. But each of them is very different and requires careful consideration. Once you have a good grasp of the scope of these modules, the usage might differ based on your business model and requirements. 

Before deciding which modules you need, make sure you have a very deep understanding of their scope and capabilities. Hopefully, this list of the non-core ERP modules will help you provide a good foundation to start your ERP selection journey. 

FAQs

Searching for an ERP solution that suits your business model? If so, the first thing you would need is to understand the functional behavior of the system based on the processes you plan to host in the ERP system. As well as how it would affect your business. While each business might need a few specific modules, most would need these common ERP modules.

Not familiar with what a module is? They are a collection of transactions or functionality like AR, AP, or inventory management. Like puzzle pieces, each module does its part of the business. The most important thing to know is how these common ERP modules fit together. And which ones you would need to wire your business model.

Each ERP system might differ in functionality and contain different modules. Some ERP systems contain industry-specific capabilities, while others are likely to be slightly more generic. Some modules are also more common and often included with most ERP systems. So which are the top 10 common ERP modules with widespread application? But most importantly, would they be relevant for your business? Review the sections below to find these answers.

1. Financial Management

The financial management module is the foundation of any ERP system, and it’s essentially inseparable. In other words, if you plan to use an ERP system, you need to replace your current accounting system. Said another way, if a system doesn’t require you to replace your current accounting system, then it’s probably not an ERP. Generally, the finance module of an ERP helps with the following activities. Things like managing accounts receivable (AR), accounts payable (AP), general ledger (GL), fixed assets, taxes, and financial reports.

For some large organizations and certain business types, the financial management module might also help with financial risk management. As well as basic budgeting. However, suppose a company has more sophisticated budgeting needs such as planning, budgeting, forecasting, scenario modeling, and performance reporting. In that case, specialized financial planning & analytics (FP&A) or corporate performance management (CPM) would be a better fit.

While most ERP systems might appear alike, the key difference between large and smaller peers would be their multi-entity and globalization capabilities. If you have a global multi-entity structure with financial synergy among them, you might need a bigger ERP system. You would need a bigger system to support the localization needs of these countries. Regardless of whether you plan to utilize any other modules, you would use a finance module with an ERP.

2. Inventory Management

Primarily used with product-centric organizations, Inventory management is another core module included with ERP systems. But even service-centric organizations may require their product and services to be coded as inventory SKUs. They need this for costing and scheduling, regardless of whether they are stocked or not. Yet another example of inventory management that differs per industry would be manufacturing, which generally has one of the most complex inventory layers such as raw materials, work-in-progress (WIP), finished goods, MRO, quality control items, kanban, fixtures, or tooling. 

Maintaining inventory layers also require keeping their appropriate units depending upon their purposes, such as sales, purchase, or consumption. So if something is measured one way when it’s bought, consumed (or sold) another way – the module automatically translates that. Lastly, this module ensures that the accounting layers are in order by handling First-In-First-Out (FIFO), Last-In-First-Out (LIFO), or average costing. 

Also, if this is your first time using an ERP (and you were on an accounting system before), you may not have your inventory formalized. It’s because the accounting systems don’t require inventory to be SKUed and instead can manage with text-based line items. Without formal inventory, you might not have issues with financial reporting and taxes. But you are likely to struggle with other issues such as costing, scheduling, and inventory planning. This is why an ERP requires you to formalize your inventory, which means each inventory item needs to have an SKU and its layers. That said, the inventory module may not be relevant for your business if you plan to use ERP just for financial reporting. 

3. Project Management

The project management module in an ERP system is relevant for companies that offer professional services or engineer-to-order products. Companies use this module to manage projects for their clients or any internal project where they need integrated costing, resource management, and scheduling. 

Since there is a very thin line between a job management of an ERP and a project, some companies might struggle to understand when they might need a project management module. In general, a project is an overarching financial wrapper that can not only account for operational project management tasks but also incorporate engineering, manufacturing, or service installation. So a project may have multiple jobs. The overarching costs for the project would account for and schedule all jobs that might be part of the project.

A project generally has a different lifecycle than a job. It might have several milestones and a payment schedule. The project management functionality also incorporates change order functionality, the changes to the original expectations of the contract or scope. Any change orders generally lead to changes in milestones and the revenue recognition cycle. The larger ERP systems are likely to contain comprehensive project management functionality, including keeping track of all invoices generated per milestone and revenue recognition cycles. But most importantly, the project management module would help you with the micro-profitability analysis. As well as consolidated scheduling, combining the demand for resources from all projects. 

4. Cost Management

The cost management module in an ERP system helps track costs across all business processes regardless of the industry or business model. While pricing depends upon costing, and most people collate them together, the scope of the cost management module doesn’t include pricing. They generally have very different lifecycles and structures and are often part of different modules of ERP systems.

For product-centric businesses, this module allows capturing different materials, labor, and overhead costs across all cost categories, such as fixed, variable, or burden. The material costs may include any costs related to manufacturing or procurement depending upon the sourcing strategy of that material. The procurement costs would include accounting layers such as FIFO, LIFO, or average, given the accounting standards, and would account for all costs, including custom, brokerage, duties, or whatever you include as part of your procurement costs. Regardless of whether the costs are likely to be direct or through a sub-contract arrangement, the costing module would help compute the total costs of your offerings.

Even for service-centric businesses, this module is crucial. Their human resources costs are likely to be higher based on their skill sets. This module tracks this across all categories, such as salary, benefits, overhead, etc., for each process that consumes human resources. The cost management functionality of different ERPs might vary based on their size. Smaller ERP systems and ones for service-focused businesses might have fewer layers of costs they track. But the bigger ERP systems provide detailed information about all the operational costs. More layers generally lead to more granular traceability and detailed analysis that companies need to plan and manage their costs. 

5. Procurement Management

The procurement management module in an ERP system is helpful in managing the execution aspect of the procurement function, whether they offer services or products. When companies require advanced procurement capabilities such as Amazon-like catalog management, guided buying, or vendor network, they might not be part of this module and instead need an advanced system such as P2P.

For product-centric companies, the procurement process is generally intertwined with their production process, as the production function is dependent upon procurement and the timely availability of materials. This module handles the entire procure-to-pay process, including purchase order (PO) management, PO matching, RFP, and RFQ management. On the other hand, service-centric companies have their procurement processes embedded with their project workflows. 

6. Service Management

The service management module in an ERP system caters to various service-centric needs. This is important for businesses that provide services along with their products, post-sale service inquiries, or pure-play field service organizations.

Depending on the design and size of the ERP system, the features included in this module might differ. For companies that offer services along with their products, this module might consist of capabilities for processing service orders, service scheduling, service inventory management, technician scheduling, and field service management. For companies offering post-sale services, this module can also handle incidents, cases, after-market serial number management, etc. The customer service module might also include the workflow of a call center or customer support work.

As far as the functionality of this module goes, there is generally an overlap between an ERP and other systems, such as CRM, OMS, or eCommerce. But the overlap is likely to be limited to the customer service side of things and not to the operational and financial aspects of service management. Regardless of whether you host this process in one system or multiple systems, if you need to measure and track the costs and centrally manage your resources, you might require a service management module of an ERP.

7. Customer Relationship Management

The customer relationship management(CRM) among common ERP modules manages different parts of the customer journey. Inside this module, you can find capabilities such as sales funnel management, marketing spend management, territory management, commission management, quoting, estimation, etc.

However, suppose your business needs more advanced features for managing your pre-sales processes, such as social media management, marketing channel attribution analysis, content management, marketing automation, etc. In that case, you might need a specialized CRM designed just for that. The CRM module in an ERP system usually focuses on operational and financial business processes, the processes that generally touch the workflow of other departments. And not the siloed processes that don’t require operational and financial collaboration with other departments.

Regardless of whether you use a specialized CRM in your architecture or not, you might still need a CRM module of an ERP unless you don’t plan to host your customers inside your ERP and use it primarily for financial reporting. Also, generally, most ERP systems are designed for B2B customers because of their structure. And since they are not the most efficient for B2C customers, you might use a specialized system such as POS or an eCommerce depending upon the channel. Based on the architecture and business processes, the need for a CRM module might vary.

8. Manufacturing Management

The manufacturing management module inside an ERP system is helpful for manufacturing industries or industries that might have similar workflows as manufacturing. This module helps manage several things, such as bills of materials, manufacturing requirements planning (MRP), advanced planning and scheduling (APS), mixed-mode manufacturing processes management, and preventive maintenance of assets.

However, suppose your manufacturing needs are more advanced, like machine integration, statistical process control, operational data collection, or edge device communication. In that case, you might need specialized software focused on these tasks. This kind of operational technology software is called MES, which stands for Manufacturing Execution System.

The manufacturing module is perhaps the most misunderstood module. In some cases, companies feel that ERP systems are generally relevant for either manufacturing companies or manufacturing processes. In other cases, they just overgeneralize manufacturing and feel that everything can be a manufacturing process, including construction or software development. While the intent of the manufacturing module of an ERP is generally operational or financial in nature. Basically, anything and everything that is manufacturing-like operations, like event management, might use the manufacturing module of an ERP.

9. Warehouse and Logistics Management

The warehouse and logistics module in an ERP system helps companies manage their storage and moving of goods through processes such as pick, pack, and ship, warehouse, and location management. 

Advanced ERP systems have even richer capabilities. These capabilities can help manage wave and batch management, carts and tote handling, cycle counting, data collection using barcode scanners, paperless and direct picking, container loading and unloading, license plate and ASN management, and global trade management. But if your business needs more specialized capabilities, like ASRS or AGV integration, slotting, 3PL capabilities, supply chain control tower, etc., you might need a specialized WMS, TMS, or a supply chain suite.

Traditionally, the boundaries of ERP and WMS systems were separate, with ERPs being primarily responsible for keeping the inventory counts while WMS was for location management. Also, some industries that were primarily designed for distribution or retail always required a specialized WMS system, so the warehouse and logistics management module of these systems was leaner or virtually negligent. In some industries, the warehouse architecture might be so different that using a warehouse module included as part of the ERP might not make sense. The newer breed of ERP systems, especially the ones that target SMB companies, generally package some basic warehouse capabilities to allow companies to manage their warehouses and logistics functions without requiring expensive integration and IT capabilities. Depending upon whether you plan to use a specialized WMS or TMS system in your architecture or not, the usage and features required as part of your warehouse module might vary.

10. Quality Management

The quality management module in an ERP manages the execution workflows of quality teams. Most companies with similar operations as manufacturing will likely require quality processes embedded with any external touch points such as procurement, returns, or production. Inside this module, you can find capabilities for different aspects of quality control, such as supplier, in-process, and RMA quality management.

This module supports features such as material review boards, quality inspections, quality certifications, and corrective action workflows if something doesn’t meet the expected quality. It also manages non-conformances and tracks how they are resolved. The presence of quality management processes can vary in different ERP systems. Some ERP systems come with these quality processes built-in, while others might not have them at all. It all depends on how the ERP system is designed.

Companies that are quality-heavy are likely to require reporting capabilities with their quality module. While the quality management module might support features such as document management or version control, it might not support operational capabilities such as documentation templates, redlining of documents, or document collaboration. For these capabilities, a quality add-on is generally a better fit. The quality module is useful for companies where quality processes are likely to impact the financial and operational workflow and is tightly embedded with the operational processes. That’s why some companies might host their quality processes externally and might not use this module.

Final Words

As you are starting the ERP journey, understanding how these common ERP modules differ is the first step to start with your selection process. While reviewing different systems, these modules are likely to appear very similar. But they each are very different and require careful review.

Once you have a good grasp of their scope, their usage might differ based on your business model and needs. So before concluding which modules you need, make sure you have a good understanding of their scope and capabilities, and hopefully, this list could provide a good foundation to start your journey.

FAQs

Regardless of how cutting-edge ERP technology might be, your current enterprise data is a major driver of operational efficiency. The efficiency that you will gain (or lose, equally likely) using your newly implemented ERP system. Understanding ERP data re-engineering issues requires mastery of cross-disciplinary processes, information modeling, and multi-system expertise. But most importantly, enterprise alignment of different processes across system boundaries. The unfortunate part about ERP data re-engineering is that even seasoned consultants struggle with it.

The biggest disconnect always is understanding the difference between data and UI/system flows as they are generally intertwined. Also, ERP data re-engineering issues are extremely challenging as they might disrupt legacy processes and transactions. So, unfortunately, no clean slate. Instead, the only option is to find a middle ground, which drives overengineering of your processes and architecture.

The ERP data re-engineering issues also make implementing ERPs for each business incredibly unique due to their differences. In other words, two exactly similar businesses and operations might yield very different ERP outcomes because of their current ERP data differences. Your data issues might be even more severe if you lived on a poorly architected system (home-grown or commercial) that substantially deviated from the enterprise software data dictionary. That’s probably the reason why moving from QuickBooks or Mainframe to an ERP is more challenging than between two standard ERP packages. The only way to cure them is to have a rollout strategy, requiring careful planning and enterprise-level control (and governance) over several years. The following candidates are the most common culprits, requiring ERP data re-engineering.

10. Work Orders/Projects

Common Issues

• Separate work orders for each routing step. The inability of legacy systems to handle long-standing transactions required segmenting into multiple work orders. But companies still carry them as part of their information model.
• Not combining all steps of a  project within it. Adjusting service or engineering costs through GL entries than incorporating them as part of the project workflow. This leads to biased total costs of projects and products/services. 
• Not implementing co- and by-products using out-of-the-box workflows. Two issues why companies struggle with them: 1) capabilities not supported with their existing ERP system. 2) Not fully understanding the intricacies of how to implement them properly.

Risks

• Misleading total costs of projects, services, and products. The disconnected information model and cost layers lead to misleading total costs.
• Overengineering of downstream workflows. Companies need to overengineer their downstream processes to resolve issues caused by these over-engineered datasets.
• Increased admin efforts to connect each work order to get consolidated insights. Connecting these individual cost drivers requires substantial admin efforts to keep track of micro profitability and costs.

Solution

• Understand the out-of-the-box data model deeply before implementing it. Don’t rush to implement. Spend time to understand the intricacies of out-of-the-box data models.
• Re-engineer your data model first before implementing it. Re-engineer as much as you can. Do it at the enterprise level, involving every function and not siloed approach.
• Vet the data model of ERP systems before buying them. Compare the data model of newer systems before selecting them. Buy only systems that closely follow enterprise software data dictionaries.

9. Inventory Allocation

Common Issues

• Different allocation states in different systems. Companies that struggle with organizational alignment often end up keeping the allocation algorithm in multiple systems, often leading to frequent departmental confrontations.
• Warehouses and channels don’t have their own inventory for allocation and reconciliation to work. Without a formal strategy for warehouses, locations, and channels, companies often end up mixing them, throwing off the allocation equation.
• Ad-hoc cycle counting processes. Ad-hoc cycle counting processes lead to inventory discrepancies, misbalancing the allocation equation.
• No formal allocation strategy or governance process. Without a formal allocation strategy and governance, the allocation equation very rarely balances for companies, causing substantial inventory issues.

Risks

• Customer experience issues. Examples such as customers not being able to place orders or not having the right amount of inventory when they require it.
• On-time delivery issues. Allocation issues lead to not being able to reserve inventory for the right customer at the right time, leading to on-time delivery issues.
• Fire fighting among departments. Not uncommon for departments to steal inventory or have physical blocking (and not keeping a record of inventory inside the system). 
• Substantial inventory planning problems. Even minor discrepancies can lead to substantial consolidated planning issues.

Solution

• Map SKUs per channel and have a dedicated inventory pool per channel. Not only maintain the SKUs per channel but also keep an accurate account of inventory per channel.
• Design enterprise allocation flows. The allocation flows are not possible unless all departments agree on a centralized allocation strategy across enterprise boundaries.
• Implement formal cycle counting processes for each inventory pool and ensure that physical and digital inventory remain close and not too far off.

8. ECN Workflows

Common Issues

• No formal ECN processes. Companies struggle to implement formal ECN processes as that requires aligning product models and a streamlined change process.
• Allowing changes throughout the process without a formal governance plan. This is especially prevalent in industries where a formal product may not exist, such as construction, sign manufacturing, or custom machinery. Their processes are different from product-centric industries, and they believe that the ECN processes might not work for them.
• No formally defined product model, making implementing ECN workflows incredibly challenging.

Risks

• Downstream issues with costing and scheduling. The shortcuts taken for the ECN process will lead to overengineered downstream processes, leading to costing and scheduling challenges.
• Issues with SKU number maintenance. ECN issues might lead to having multiple SKUs for each change or product model not connected, driving substantial part maintenance issues.
• Misleading insights.  Not accounting for the costs of changes appropriately will lead to misleading insights. 

Solution

• Define the product model. Even if you might feel that you don’t have one. The foundation of ECN relies on a streamlined product model.
• Formalize ECN processes. Build ECN workflows and build consensus with all stakeholders involved throughout the ECN process to ensure compliance.
• Re-engineer legacy processes because of poorly implemented ECN controls. Re-engineer any legacy over-bloated processes due to the poor implementation of ECN prior to implementing a new ERP.

7. BOMs and Revision Numbers

Common Issues

• Revision numbers not utilized. Separate SKUs for each revision. This is a major issue with companies when they might not have a formalized process for maintaining revisions.
• Return implemented as a routing step. This is common with companies that may not have had return capabilities baked as part of their legacy system and had to take a shortcut to implement it. But these companies still carry them as part of their information model.
• Mixing of different hours limits the traceability of different activities. Companies on legacy systems that didn’t support reporting of hours individually or took shortcuts because of the perceived increased effort generally struggle with the traceability of different activities and their cost implications.

Risks

• Costing and scheduling issues with BOMs. The issues with the underlying structure of BOMs and revisions generally lead to substantial costing and scheduling issues. 
• Unreliable insights produced despite substantial admin effort reconciling various data silos.

Solution

• Implement BOMs and revision process using the out-of-the-box functionality. Understand the intricacies of out-of-the-box capabilities of BOMs and revision numbers and implement them without hijacking any existing workflows.
• Re-engineer BOMs and revision numbers as much as possible before implementing a new ERP system. Don’t implement them as is. Analyze BOMs and revision numbers and assess if re-engineering them might be possible without disrupting the support for legacy processes and transactions.
• Reduce manual intervention for BOM data entry. The more manual intervention you have in the process, the more data quality issues you are going to have. So replace the entry of BOM and revisions using CAD add-on if possible.

6. Chart of Accounts

Common Issues

• Too verbose. The companies outgrowing accounting or smaller ERP systems generally tend to have flatter structures for charts of accounts due to their limited number of hierarchies and layers. 
• Chart of accounts barely mapped with lean hierarchies. The legacy systems might support the mapping of a chart of accounts, but the hierarchies may be leaner, limiting the traceability.
• Reconciling through GL entries. Companies outgrowing smaller systems have a tendency to reconcile account balances using GL entries.

Risks

• Maintenance issues. The verbose chart of accounts would increase the admin efforts in maintaining the flatter hierarchy and reconciling them.
• Challenging to get insights from ERPs. Getting insights may not be possible with the flatter hierarchy as the underlying layers may not be enough for the required traceability.
• Significant financial control issues. The practice of updating GL balances directly may cause substantial financial control issues because of the limited traceability of the original transactions. GL entries should be limited to non-operational ad-hoc transactions and definitely not to reconcile operational accounts.

Solution

• Model chart of accounts after the system-provided chart of accounts. ERP charts of accounts are different from accounting software, and they need to be re-engineered and mapped in appropriate hierarchies to get desired insights.
• Utilize ERP hierarchies than making them verbose. Follow ERP hierarchies as much as possible. Bypassing them may cause traceability issues.
• Avoid direct GL entries for operational transitions. Avoid GL entries for operational accounts as much as possible, especially accounts that might be harder to reconcile, such as inventory or channels.

5. Customer/Vendor Master

Common Issues

• Customer/vendor master model mixed with another master data business object. Companies end up mixing the master data models, such as implementing 3-tier hierarchies of the customer master using a dropdown on a product maintenance screen. 
• Inconsistent modeling of child and parent business objects. Mixing child objects with parents, such as implementing ShipTos as customers or vice versa.
• Three-tiered hierarchies are not maintained in the system. 3-tier hierarchies, such as buying groups or holding companies, require implementing them using out-of-the-box capabilities. Instead, they take shortcuts such as making them 2-tier and then overengineering processes to get insights.
• Retail customers modeled as orders. Making decisions such as bundling all retail transactions under one customer account causes substantial performance and maintenance issues.

Risks

• Slowed customer service. Overly bloated business objects cause performance issues, increasing the total time required to serve customers.
• Overengineered workflows. Overengineered workflows may require further over-engineering to overcome the shortcomings of underlying workflows.
• Scalability issues. Without understanding the implications of mixing technologies, issues such as using EDI for integrating internal customer channels may lead to scalability issues of codes, causing issues with onboarding new customers.

Solution

• Maintain the natural hierarchy of business objects. Don’t deviate from the real-world hierarchy of the customers and re-engineer it if possible to align with the selected ERP system.
• Have a master data governance plan in place. Implement master data governance plan and implement them using workflow technologies if possible to reduce the number of variations with inputs touching customer master.
• Limit the creation of customers/vendors to power users. Limit the number of users adding records impacting master data.

4. Sub-accounts

Common Issues

• Implementing too many unnecessary sub-accounts. Companies with a limited understanding of sub-accounts might end up using too many of them, adding unnecessary steps with each transaction.
• Not modeling the right dimensions with the sub-accounts to get the desired traceability. Not implementing sub-accounts where they are fit leads to uncontrolled growth of chart of accounts or overengineered processes.
• Implementing sub-accounts as a chart of accounts. Implementing sub-accounts as the chart of accounts causes charts to be too verbose.

Risks

• Slowed processes because of unnecessary data entry at each step. The unnecessary work just to enter data required for sub-accounts may increase additional steps with each process and may slow down operations.
• Lost traceability. Not modeling sub-accounts where they would be appropriate would lead to the lost traceability of transactions.
• Bloated chart of accounts.  The verbose chart of accounts causes sustainability issues in the long term.

Solution

• Thoroughly analyze sub-accounts. Think  10x before deciding to implement sub-accounts. They can break your entire implementation and are much harder to reverse.
• Don’t implement too many sub-accounts if they are not really part of the operational workflow. Unless absolutely required by operational workflows, don’t implement them.
• Implement sub-accounts in the FP&A software if possible. The FP&A software provides much more flexibility in adding more dimensions without disrupting operational workflow.

3. Serial/Lot Numbers

Common Issues

• Using project numbers or dates as serial numbers. Companies often mimic serial or lot numbers using random numbers such as project# or dates and then would be required to build the entire workflow to support serial or lot number processing that would have been available out-of-the-box with the system.
• Mixing of serial or lot numbers. Companies that don’t fully understand the lot and serial numbers end up mixing the schemes, causing traceability issues and increased admin efforts.
• Not implementing lot numbers appropriately. Some companies that may not fully appreciate the out-of-the-box lot control functionality end up hijacking processes and overengineering workflows.

Risks

• Traceability issues with serial and lot numbers. The biggest implication would be traceability as you build workflows that are dependent upon serial and lot numbers.
• Hijacked processes lead to further over-engineering. The ERP processes are so interdependent and intertwined that once you hijack one process, the dependent processes would start breaking and would require further hijacking.

Solution

• Use the serial numbers model as provided by the system. Understand the workflow fully. Buy a system that has serial number capabilities aligned with your processes.
• Don’t hijack out-of-the-box workflows to accommodate broken processes. Stop the urge to hijack processes. Instead, invest effort in understanding the intricacies of the out-of-the-box processes.

2. UoMs

Common Issues

• UoMs don’t mimic the natural hierarchy of data. Companies that don’t use a natural hierarchy compliant with sales, purchase, and production processes often struggle with substantial planning or operational issues. An example, such as implementing a product that is generally sold in rolls as EA would cause downstream issues.
• UoMs modeled as dropdown options or form fields as opposed to coding at the SKU level. Companies that don’t fully understand the difference between the data and UI flows end up implementing UoM issues as dropdown values.
• Purchase, production, or consumption UoMs not modeled appropriately. Companies that don’t fully understand the implications end up opting out from modeling each of these categories, causing issues with the downstream processes.

Risks with

• Over-customization of workflows to fix the issues caused by data. Unnecessary hierarchies of data often drive substantial overengineering of downstream processes and operational inefficiencies.
• Business performance issues such as MRP etc. Not following the natural hierarchies of UoM will lead to requiring substantial admin efforts with MRP suggestions before they are meaningful for business operations. It also leads to lost trust in system data.

Solution

• Follow the natural hierarchy of UoMs. Follow the natural hierarchies of UoM. Trace every single transaction and vendor and identify the UoMs on how materials are being sold, procured, or consumed.
• Fix UoM issues first before implementing a new system. Re-engineer UoMs prior to selecting and implementing a new system. Not aligning UoMs will lead to substantial planning issues even with the new system.

1. SKU Numbers 

Common Issues

• Flat SKU numbers without hierarchy. Modeling revision numbers as SKUs. Implementing each UoM as individual SKUs. Flattening the variable or dimensional inventory. These are examples of where companies flatten their inventory.
• Too much intelligence built into SKU numbers. Companies on legacy SKUs that they can’t retire might have substantial intelligence built as part of the numbers or in the description, which leads to scalability and maintenance issues.
• Mixing of automated and manual numbering schemes. Inconsistent numbering scheme. Using an outside number generator to generate SKUs without native controls built up might lead to maintenance issues with inventory.

Risks

• Difficulty in extracting SKU-level insights. The intelligence built as part of SKUs or flattening them might make extracting SKU-level insights challenging and would require substantial admin efforts to reconcile each SKU-parts to extract insights.
• Challenging to plan at the SKU level. The planning cycle assumes getting reliable data at the SKU level. Poor modeling of SKUs poses challenges in extracting reliable data at the SKU level, which is the foundation of most planning cycles done at the SKU level.
• Misleading business decisions. Flattening of SKUs and the inventory model being all over the place lead to misleading business decisions.

Solution

• Don’t build too much intelligence with SKUs. Be especially careful with any intelligence embedded as part of the SKUs or descriptions. 
• Use the automated numbering scheme. The one that is natively built with the system.
• Clean the SKUs before implementing a new system. Try to re-engineer the SKUs as much as possible before implementing a new system. And if ERP data re-engineering is not possible, try to come up with a rollout plan.

Final Words

Unfortunately, there is no way to get rid of ERP data re-engineering issues due to the need to support legacy processes and transactions. But not re-engineering them prior to implementing an ERP can lead to overengineered processes and overly bloated systems, sometimes leading to overall operational efficiency loss despite your investments.

So if you are thinking of replacing a new ERP, invest some time thinking through how you plan to re-engineer your current data. You also need to find a system (or combination of systems) that’s closer to your current information model. But don’t stop there, as ERP data re-engineering would require a roll-out plan spanning over years if you want to be even closer to getting rid of all of your ERP data issues. 

FAQs

Who wants to deal with an ERP selection RFP? Literally no one. They are boring, dry, and unnecessary. Everyone is generally super frustrated with them. Because of this issue, some companies choose not to compete in opportunities requiring an RFP. The customers are equally afraid of writing one because of the fear of not getting traction from ERP vendors. But the problem is not necessary with the RFP process. It’s how companies write them. Not understanding their true intent and not realizing that the ERP vendors are running businesses as well. A process that they might perceive as unfair or unnecessarily difficult will make it challenging to drive their interest.

The intent of an RFP must be to document details that might require weeks or months for vendors to comprehend. Capturing it into an organized document helps them understand the need and assess if their solution would be fit or not. Write them to reinforce details covered during the demo. Because with systems as complex as ERP, most attendees are likely to retain only 10% of the demo, missing out on critical details. Reinforcing through the written process helps ERP buyers and vendors avoid missing critical details, which might be vital for the success of an ERP project.

The more experienced the writer is in relationship-oriented roles, especially in sales and negotiations, the higher the quality of RFPs. Generally, writers with little exposure to customer-facing roles such as finance or IT are likely to make it overly difficult. These components will help you structure your ERP RFP with the right amount of details.

10. Selection Process

Its Importance

• Communicating the seriousness of the project. Believe it or not, ERP vendors are super selective about deals unless it’s a VAR or a smaller vendor. They might not want to complete the deal if they perceive that you are not serious. Setting expectations about the selection process helps avoid unnecessary churn and disinterest.

Common Mistakes

• Not spelling out the ERP selection process. Not including the right amount of details that vendors would need to get approval at their end. As well as to assess that this would be the right opportunity for them.
• Not agreeing on the steps of the process. Companies considering ERP selections in the DIY mode might not formalize the process and may take forever to decide, disengaging credible ERP vendors.

Details That Matter

• Steps of the ERP selection process. Details such as how many phases would be part of the process. How you will make decisions. Who will advance, and who will not? What will be the decision criteria, and who will be the decision-makers? Communicating steps of the ERP selection process not only helps in aligning expectations but also in managing scheduling and ensuring that key resources are available to support the ERP selection process.
• Dates and timelines of key activities. Do you have a defined timeline for ERP selection? How about dates for the activities, such as ERP selection or demo? Including dates and timelines helps set the expectations that you have a structured process and you are not going to take forever to decide, giving the credible vendors the confidence they would need to engage with you.

9. Proposal Evaluation Criteria and Delivery Instructions

Its Importance

• To communicate that the process will be fair. Communicating fairness is critical to encourage vendors to have their best shot. Without this, getting sufficient details to evaluate a solution would be a challenge.
• To convey that RFP is not just a formality. Vendors disengage as soon as they feel that ERP selection RFP is just a formality and may be written to favor a specific vendor.
• To let the vendors evaluate if they are the right fit for this opportunity. Provide proposal evaluation criteria to help them assess their fit. They are likely to be more honest at the beginning of the process if they have not invested as much time in the opportunity.

Common Mistakes

• Making the process overly complex. Making the evaluation process overly complex might discourage vendors who might be an ideal fit for your business.
• Coming across as wasting ERP vendors’ time. They might not choose to compete If you come across as wasting their time, even if they might feel that their product might be a fit.
• Making the process unnecessarily difficult, like only accepting mail. Overly difficult processes miscommunicate that you might be difficult to work with, and they might disengage.

Details That Matter

• Detailed evaluation process. Specifics about the evaluation process, such as elimination rules and variables of decisions about how ERP vendors will advance at each round. 
• Clear delivery instructions such as point contact and how they can reach the contact person if they might have any questions.

8. Current Team and Org Chart

Its Importance

• To communicate that the right decision-makers are involved. Including information about the team and their titles help vendors understand the process has been thought through and that you are serious about the ERP project.
• To let them research the team members involved and tailor the communication to their needs. Details about team members help them research team members’ backgrounds and tailor communication to their needs and make it relatable for users.

Common Mistakes

• Being overly secretive about the team members. Regardless of the reasons why you might not choose to communicate about the team involved, being secretive will raise doubts about your seriousness.
• Not communicating their roles and responsibilities and alignment with the project. Including team members is important, but what is even more critical is communicating their project roles. Details such as their responsibility for specific business processes or their decision-making authority for specific functions or processes.

Details That Matter

• Names and the titles of the team members involved. Allowing them to research their background to help tailor communication.
• Their role in the project. It helps them create role-play stories and tailor demo scripts.
• Expected during the demo. Including who is expected during the demo will help not waste time in creating stories and scenarios from the perspective of users who are likely, not present during the ERP demo.

7. General Guidelines

Its Importance

• To communicate any general expectations not related to the project, such as vendors’ financial standing or legal proceedings
• Communicating overall expectations from the relationship. They help in communicating any regulatory constraints and overall expectations that might not be directly related to the ERP project.

Common Mistakes

• Being overly verbose with rules that might frighten ERP vendors. The companies that either use boilerplate RFPs or just copied and pasted text might discourage savvy vendors who might be a potential fit for your business.
• Including boilerplate rules that might not be relevant to the project. Including boilerplate rules not directly related to the project is likely to cast doubts on your seriousness with the project.

Details That Matter

• General rules such as highlighting add-ons, white-label products, and integrations. Details such as add-ons vs. white-label products help clear up the ownership if there might be any third-party components used to power the entire solution. As well as any other overall expectations not specific to the project.
• The cost of the RFPs. Include details, such as proof of concepts if they are likely to be paid.
• Any legal obligations. Any legal obligations, such as pending judgment against the vendor, and if that might be a factor in deciding against a vendor. Legal details such as copyright or NDA.

6. Business Goals

Its Importance

• To communicate overarching project objectives. Spell out what you are trying to accomplish, be specific.
• To let vendors help in assessing the feasibility of the to-be state. Without this, challenging would be if their solution is a fit.
• To connect the dots with other components of the ERP Selection RFP. How other sections relate to each other.

Common Mistakes

• Not including business goals. Without business goals, they might struggle to evaluate if their solution would be fit or not and unknowingly overcommit.
• Being too vague with goals. Generic goals are likely to mislead as they might misinterpret them differently than how you intended them to be.

Details That Matter

• What are you trying to get from this project? Details such as overall objectives from the project and any specific KPIs that you might be thinking of hitting.
• Expectations for your goals. Sets clear expectations on your priorities so there is no confusion in how they interpret them in their heads vs. what you want.

5. Business Challenges 

Its Importance

• To communicate the overall drivers. The challenges help them understand what’s driving the project and if the solution is going to be a good fit or not.
• To help them connect the dots about your needs. The business challenges help connect the dots about the critical success factors and key needs outlined.

Common Mistakes

• Not including the challenges. Not including the challenges is likely to communicate a biased perspective,  missing out on crucial details required to evaluate a solution.
• Being too vague with challenges. Be as specific as possible to avoid misinterpretation.

Details That Matter

• What challenges are the trigger for the project? Specific details such as drivers and triggers for the project.

4. Future State

Its Importance

• To connect the dots on what might not be relevant from the as-is state. The future state is important to understand the rollout plan for legacy processes and transactions and if they need to treat legacy processes as requirements in the new model and architecture.

Common Mistakes

• Including the wishlist might confuse them more than it could help. The wishlists, which are not specific, may be assumed as needs, putting the entire ERP project at risk.
• Not identifying the future state. Missing the future state assumes the broken as-is needs as requirements.

Details That Matter

• Specific details about the future state. What’s going to be relevant in the to-be state? What’s going to be changed? Include the rationale for what’s being included and what’s not.

3. Current State

Its Importance

• To help them understand the complete story. The current state of the business is important for them to understand the as-is state if they might drive any issues with the future architecture. 
• To help them assess if their solution is a fit. The as-is details will help them assess if their solution would be a fit or not. Without the as-is state, it’s hard to assess if there might be any required customizations, especially why legacy processes can’t be streamlined and aligned with out-of-the-box capabilities.

Common Mistake

• Intentionally hiding the critical details for fear of miscommunication. The ERP buyers often choose to hide details that, they feel, might confuse the ERP vendors.
• Missing critical details of the current state. Not documenting the current state with the right specificity will lead them to assume details that might not be intended.

Details That Matter

• Specific current processes. Details about current processes, such as how they are done right now and what was the rationale behind doing it this way.
• The rationale for any changes. The rationale why the processes would need to be changed.

2. Current and Future Systems

Its Importance

• To communicate how many systems are involved in the architecture. Depending on how many systems are involved and their role, the scope of the new system might vary.
• To communicate the need for integration and process boundaries. The systems would help understand the integration and process boundaries of the new system.

Common Mistakes

• Only including a few systems. Companies tend to ignore systems that they feel might not be relevant, only to learn later their importance for architectural feasibility.
• Including systems that might not be relevant to the project. Not having a clear understanding of which systems to include might lead to over-communicating systems that might be completely irrelevant, confusing the ERP vendors.
• Not including versions and specific product names etc. Not including specific details such as product name and version numbers might lead to vendors making assumptions, leading to a biased system selection.

Details That Matter

• Name of the products and their versions. Include the name of specific products and their versions.
• How the products are being used in the current architecture. Describe their role in their current architecture, including their integration flows with other systems in the architecture.
• How they are expected to be used in future architecture. What would their role be in the new architecture, including any integration needs?

1. Critical Success Factors

Its Importance

• To avoid brush-offs during demos. Including the critical success factors and asking vendors to respond as part of an RFP can help where vendors might brush off if they might be weaker with those capabilities.
• To stay focused on factors that are likely to make or break the implementation. 
• What’s most important for selection and that the system will be a good fit? The critical success factors help communicate the factors most critical for selection and implementation.

Common Mistakes

• Including factors that might not be as critical. ERP buyers not savvy with requirements analysis with limited knowledge of the ERP industry include critical success factors that might not be as critical.
• Being too vague with critical success factors. Identifying specific critical success factors requires deep ERP implementation expertise that most companies don’t understand and end up choosing that is too generic, giving ERP vendors a leeway to brush off capabilities where they are likely to be weaker.

Details That Matter

• Critical success factors. The factors that make or break implementation are likely to influence the budget and timelines of the project.
• The questions related to the critical success factors. Which questions are you seeking answers related to these critical factors? These questions will provide the context of why these factors are critical for you.
• Whether the critical success factor is a show-stopper or not. Some systems may require workarounds as their capabilities might not be fully hashed out around these success factors. So they might not choose to compete. Identifying show-stoppers would help give them confidence that they have a shot at winning this opportunity.

Final Words

Treat the RFP process with the true intent, which should be to make the selection process easy and convenient, and not difficult. Avoid boilerplate details as much as possible. Write it because it will help teams consume the same information through multiple channels several times, making sure that most critical success factors have been hammered thoroughly. Also, document because it will align the expectations of both parties.

Including an RFP with the selection process will help reinforce and ensure not to miss out on critical details while creating a fair and comfortable process for all ERP vendors involved. But make you hit on these components to provide a convenient experience for all vendors so they feel that you are the kind of customer they would go out of their way to help.

FAQs

Where do you draw the line between the ERP selection process and implementation? It’s a tricky question. Because of this, various schools of thought exist: does it make sense to invest in process documentation? When to clean your data? Let me give an easy answer: it depends. Easy, wasn’t it?

Opinions differ primarily because of varying expertise among ERP selection vendors. Also, what exactly is ERP selection? Is it just meeting a bunch of functional requirements the way you would buy shampoo? Or would the selection process be as involved as the engineering phase of a large aircraft? Some ERP vendors without implementation expertise argue against a thorough selection process. They emphasize project and change management as the keys to success. Although there is no consensus on the lines of change management, one thing is clear: if you don’t re-engineer your data and processes, the new ERP is just a lipstick on a pig. So whether you perform process and data re-engineering during the selection or implementation phase, it’s a vital step in the ERP selection process.

The other challenge with the ERP selection process is even trickier. A challenge that the entire ERP industry faces, primarily because it’s chicken and egg. And that is, you can’t be confident in design and architecture until you’ve selected a system. But once you choose, you’re locked into a contract and constrained by that system’s boundaries. Also, investing too much in the selection process might kill the project even before it starts. Understanding these ERP selection steps will help structure your project based on your needs.

1. Project Initiation

Project Charter. The components of a project charter include identifying a specific project vision and objectives and as-is and to-be KPIs. But most importantly, a budget/timeline that you can use as a measuring stick throughout the ERP project. A common mistake organizations make is not writing down the project charter. Or not being specific enough that it ends up collecting dust on a shelf. But why do organizations struggle with this? Well, it requires mastering critical reasoning skills to craft compelling objectives and choose the right KPIs. 

Stakeholder Matrix. The stakeholder matrix is perhaps the second most critical item of the ERP selection process. It identifies the different stakeholders involved, their hierarchies, the escalation matrix, and how decisions will be made. Not having clear accountability and people’s names printed against decisions generally result in each decision taking forever. Or the most authoritative figures simply highjacking processes without fully understanding the implications. Here are other elements that are equally critical: Identify the core team, a steering committee, and a communication plan.

Discovery Workshops. Let’s face it. 40% of the processes inside an organization are just tribal knowledge. The role of discovery workshops is to uncover trial knowledge through a series of demos. Also, don’t believe everything that users report. Verify and validate it through multiple sources. Gather as much data as possible, dig into the systems, and analyze data hierarchies. And use a process mining tool if you are a large, complex enterprise. Embrace your inner detective and leave no blood drop untraced. 

2. Requirements Workshops

Requirement Matrix Draft. Once you wrap up the discovery phase, you’ll have hundreds of requirements for each division. You’ll know which systems currently hold them and which ones will in the future. This information is crucial for shaping your enterprise architecture and interaction workflows. However, many functional ERP selections overlook this step, assuming that ERP is a solution to all problems. Don’t fall into that trap—and host the requirements where they make sense and where they would be compliant with architectural and master data governance guidelines.

Requirements Workshops. The purpose of these workshops is to go over each requirement and make sure that the team understands the as-is and to-be state. The team must also agree on the process boundaries and critical success factors. These workshops act as a second validation to catch any missed requirements from the discovery phase. Successful workshops will uncover important details that can impact the selection and enterprise architecture.  But don’t forget to build consensus on critical success factors, as well as a priority for each requirement.

The Critical Success Factors. Critical success factors are the key needs that can make or break an implementation. They are the ones you must prioritize during the demo. However, many companies get caught up in non-critical details like how a system processes a sales order or the availability of an Outlook add-on. While important, these details may not be the critical success factors. Here’s a rule of thumb: just as having too much sugar is bad for you, having more than ten critical success factors missing can lead to overlooked critical details and implementation issues. 

3. Business Process Re-engineering Workshops

Process Visualization. Unless your users implement ERP for a living, their expectations of a system are likely to be vague, with risky financial and technical assumptions. It’s similar to buying a house and agreeing on a specific color without understanding if the chosen shade of color will fit the context. To align expectations, you need iterative exercises of visual models designed to refine your understanding of as-is and to-be states without locking in a contract. 

Process Re-engineering Maps. This step restructures your process in compliance with enterprise software or ERP dictionary in a vendor-agnostic manner. While the ideal outcome would be a clean state aligned with the ERP dictionary, it might not always be possible. Because the legacy processes might be required in the new architecture to support legacy transactions. So perform a careful analysis of which processes can be restructured. As well as how that would impact information models and enterprise architecture and what would require a rollout plan so you can follow an iterative approach to phase out legacy transactions and processes.

Balancing of Perspectives with Maps. While re-engineering is helpful to avoid expensive overengineering and customizations, it may not fully satisfy every stakeholder unless the maps are translated from their unique perspectives. Users and technical teams have different needs. So, it’s important to create two versions of the maps: one tailored to the users’ perspective and another focused on implementation. While the internal team can handle the as-is version, creating effective to-be and implementation-centric maps requires specialized expertise. Drawing maps may seem simple, but it’s far from it. It takes years of experience with ERP implementations to create truly impactful maps.

4. Data Re-engineering Workshops 

Data Re-engineering. Understanding how data hierarchies impact the process and system decisions is perhaps the hardest part. In general, data is not easy to re-engineer. Maintaining the state of master data over a period of time is equally difficult, even for the most disciplined organizations. Also, once the master data is printed on labels or communicated to external parties, refactoring and communicating why it’s needed becomes extremely challenging. So you might not be able to start with a clean state, but you need to re-engineer as much as possible.

Master Data Governance. Master data governance is not just a system concept. It requires defining organizational workflows across system and process boundaries. Things such as where master data gets generated, who maintains it, and how it is augmented across enterprise boundaries. As part of this step, build the source of authority matrix for each dataset. Examples of datasets would be the dependencies embedded with the main master data objects such as customer, master, items, and chart of accounts. But don’t forget to build the governance processes, such as what is a customer vs. what is a parent account? How to set up various master datasets such as charts of accounts and customer classes etc.

Reconciliation Workflows. The reconciliation workflows analyze the transactional data and how it will be reconciled across system boundaries. Analyze every GL reconciliation scenario and perform the root cause analysis to understand if the current GL reconciliation might be a symptom of weaker reconciliation upstream. Your goal should be to analyze the source of the variance both in the as-is and to-be state. Reconciliations workflows will help make decisions about process and system boundaries. 

5. Enterprise Architecture Development

User/Department and System Workflow Mapping. Think of these flows as very similar to process maps, but rather than mapping process boundaries per department and function, you are overlaying the system layer per user and role. As well as how each department would be interacting with systems. You not only identify the primary systems that every user, role, or department would use, but you would also identify the second and third systems for the root cause analysis and reconciliation. While you are defining the system view, it is only done at the category level and not necessarily from the perspective of specific technology or vendor. 

High-Level Design. The high-level design is the business view of enterprise architecture. Its role is to define the roles and responsibilities of each component and major messages exchanged among systems. The high-level view does not account for technical concerns, such as how every technical error will be handled. This helps technical teams understand the business outcome from their perspective. 

Detailed Design. The detailed design specs are prepared by the technical teams in response to high-level design. The detailed design identifies most technical exceptions and workflows and major pseudo code to identify the test cases and stories. As well as the integration messages in the format the systems would consume. The detailed design helps align the business and technical teams on the expectations of business outcomes. The detailed design also identifies any proof of concepts that need to be done to remove any technical or financial risks.

6. RFP Development

Write RFP. The challenge with vendor-agnostic architecture is that it might feel like shooting in the dark without a frame of reference. And sometimes, RFP development may occur before the detailed design is fully hashed out. Also, whether you plan to include an RFP as part of your ERP selection process or not, writing it saves time as you don’t have to repeat details with every vendor. The RFP contains sections such as as-is and to-be state, current and future systems, business channels and goals, but most importantly, critical success factors. 

Design Evaluation Framework. The evaluation framework is a quantitative framework that helps shorten the long list of systems and create a short list of vendors and solutions identified to vet through the selection phase. The evaluation framework also identifies weights for each critical success factor and decision criteria that the teams can understand and use to evaluate different systems and vendors. The sooner you get agreement on the evaluation framework prior to the demo, the less confused your team members are likely to be. The evaluation framework will be updated throughout the ERP selection process and will be the foundation for vendor scorecards. 

Evaluate Written Responses. While some people disagree with the need for written responses, they can help reinforce findings or discover additional questions that may not have surfaced during the initial phase. It also helps teams understand the layout of different systems prior to looking at demos. The written responses would also allow you to vet your critical success factors thoroughly or change them as you learn more about vendors’ capabilities.

7. Vendor Demonstrations

Demo Scripts. This step focuses on designing scripts that vendors use to structure their demos. Most vendors will try to focus on the strong aspect of the system, brushing off critical features where they might be weak, ending on a positive vibe. Demo scripts help you stay organized and focus on the factors that matter most for your implementation.

Brief Vendors. Vendors are likely to have millions of questions just to prepare the ERP demos. Sometimes, you might want to do this prior to the written responses, while other times, it might be right before the demos. But briefing vendors is a crucial step. They need to understand enough about your business for them to be able to prepare the demo in a way that would resonate with the users who might not understand how different ERP systems compare.

Organize Demos. This step focuses on organizing demos with each of the vendors. Some ERP vendors might be open to onsite demos, while other vendors might prefer a virtual option. In general, your goal should be to organize demos in 2-4 hrs windows. If you keep the demo duration longer than this, the users might struggle with their attention span. If you keep it short, the vendors might not appreciate it as they may not be able to describe the capabilities in detail. You might require several rounds of demos depending upon the comfort level of the team with different systems. The first round is likely to be more of a high-level understanding of the system. The next round of demos is likely to be around specific critical success factors or roles.

8. Vendor Score Cards and  Fit Gap Analysis

Update Vendor Scorecards. After each round of demos, you might need to create vendor scorecards, which are likely to have a very similar structure to the evaluation framework. The vendor scorecards help keep track of things and maintain their ongoing ranking. Not having access to vendor scorecards will lead to teams being confused and might end up choosing a system that might not be the best fit. The vendor scorecards also help neutralize the biased powerful voices that are likely to hijack decisions in their direction, misleading the ERP selection processes and resulting in technical and financial risks in the implementation phase.

Perform Fit-gap Analysis. The fit gap analysis goes hand in hand with analyzing customization and data migration efforts required with each solution set. This step compares as-is processes and data with each solution and identifies gaps that would require more than just simple configurations and testing in the system. Depending upon the sequencing need, this step might run parallel to the detailed step or may be sequenced before or after. This step is essentially flavored for each potential solution and is a brief risk assessment for each solution considered. The ERP implementation phase will merge the detailed design and the finalized solution from this phase and build on top of it.

9.  SOW and Contract Negotiation

User License Access and Cost Analysis. This step maps out all users (or user groups) and their access requirements across different solutions considered. It will also dig deeper into the enterprise architecture and user-system mapping matrix to map appropriate access rights for each user profile. The user license access then needs to be aligned to each solution type to identify any licensing risks which might result in overages or toll charges after signing the contract. If not analyzed thoroughly, these charges may end up eating savings gained through negotiations. The licensing needs also need to be analyzed for any API or system-related access rights.

TCO and ROI Analysis. This step builds out a cost schedule for each solution considered over a pre-determined time horizon. By accounting for all cost elements, including internal and external costs, this step will help plan the budget for the entire initiative throughout the project. This step will also identify potential cash flows expected over the period of time based on the synergies and efficiencies expected over a period of time. The financial analysis helps executives gain confidence in the initiative and help plan the cash flow over a period of time.

Contract Analysis and Negotiation. The goal of this step is to analyze any financial and legal risks buried in the contracts. By combining insights from enterprise architecture and user access rights, this step analyzes issues such as storage, bandwidth, data migration, vendor conflicts, and vendor support. After identifying major risks with contracts, a negotiation strategy is developed with each vendor. Based on vendors’ counter strategy, revisions might be required with the overall plan before finalizing a vendor and awarding the contract.

10. Implementation Planning

User Stories and Sprint Planning. This step plans the implementation phase in how different sprints will be structured and sequenced depending upon the configuration, customization, and integration required. It expands on the requirements captured in the requirements matrix and develops acceptance criteria that are used to create a quality plan and testing strategy. The sprint planning is also aligned with other change and program management deliverables that need to be planned together to avoid any cost overruns.

Quality Assurance Plan and Test Cases. The quality assurance plan develops the test strategy aligned with each testing step, such as unit and integration testing, as well as UAT. It also develops a compliance framework to ensure accountability from each user and department. Aligning the acceptance criteria identified with user stories, the quality plan is used throughout the implementation phase to avoid surprises post-implementation because of untested code and scenarios.

Implementation Readiness Prep. This step is used to finalize the risk management plan, resource planning, current system refactoring plan, data migration strategy, and change management plan, along with how each will impact the critical path. The goal of this step is to track all dependencies that need to be captured as part of the project plan to avoid any financial and schedule surprises.

Final Words

Most companies struggle with the decision of whether to invest in a selection phase. But deciding how much to invest and how to structure your selection phase could be an even more difficult decision. 

So if you are planning for your ERP project, make sure to include these phases as part of your ERP project. Don’t wait for that day when the lines between the selection and implementation phase would become clearer. That may never happen due to the nature of the beast. 

FAQs

Understanding why ERP selection matters requires alignment on the output of the process, but what’s the output? Right software? Consensus among teams? Sweet discount? ERP selection deliverables? But watch out, even success can be tricky. What if your initial success might fall on its face? What if your implementation teams shred the initial recommendations? And what if users or customers don’t buy into critical assumptions made during the selection phase? All Investments might go down the drain. Ouch! 

Once you understand these ERP selection deliverables, comparing ERP selection vendors is generally much easier. Some vendors might not even understand their importance and might argue against them. But they argue because of their skillset, claiming this responsibility is to be of tech vendors. Holding tech vendors accountable for these deliverables is like hiring two parties who speak two completely different languages, and none of them have the capabilities to translate confidently without losing something in translation. They not only need to deliver them but with the right depth that technical teams feel comfortable taking over.

Without consensus on ERP selection deliverables, building a business case for the project might be equally harder. How do you estimate the costs of something if you haven’t defined what it is that you are estimating? Even movers need to know the details of the shipment to estimate the costs. ERP implementation is like moving the whole city. Too many variables. And this is where these deliverables can not only help vet the qualified ERP selection vendors. But they can set the tone of the project to be successful with it.

1.  Project and Implementation Charter

The role of the project charter is to list the key objectives and KPIs that are going to set the tone of the project. It also outlines the scope, budget, and timeline expectations at the 30K foot level. The goal of the implementation charter is generally a similar document but primarily for the implementation phase, which would be written at the end of the selection phase.

Why it’s important

• Without it, it’s very hard to build a consensus. Aligning teams requires a set of guidelines that they can refer to in case of conflict.
• Hard to stay on track. The guardrails help them stay on track.
• Hard to measure success. Measuring success require clearly defined objectives.

Common issues

• Objectives are not specific enough. Test your objectives with SMART criteria. S = specific, M = measurable, A = achievable, R = realistic, and T = timely.
• KPIs are not measurable. KPIs need to be specific and measurable. 
• Does not evolve over time. Project charters are meant to be ongoing documents that need to be updated as constraints change in the project.
• Doesn’t capture the budget, timeline, and scope. No budget or timeline expectations can lead to researching ideas that might not be worth exploring and may result in sunk costs.

How to do it right? 

• Follow SMART criteria. Following the SMART framework will help you identify objectives and KPIs that will serve as the guardrails for the project.
• Don’t let it dust on the shelves. Go back to it when you have a conflict within the team and evolve if it is already outdated.

Project and implementation charter documents set the tone for the project. They are essential to build consensus and resolve conflicts.

2. Stakeholder Matrix

The stakeholder matrix helps define the roles and responsibilities and sets the right expectations with teams and stakeholders when conflict arise. It also defines the escalation path when things go awry.

Why it’s important

• Who is going to be making decisions and when. Identifies the responsibilities of each stakeholder with a RACI matrix.
• How many different subsidiaries be aligned, and who is the point contact? Defines the relationships between different subsidiaries and entities and their interaction model.
• What is the escalation hierarchy if things don’t go well? Identifies the escalation matrix in how escalations will be handled.

Common issues 

• Not involving the right teams and decision-makers in the process. Not involving the users in the process who might not buy into the decisions made by stakeholders identified in this matrix.
• Not defining the RACI chart for everyone. RACI chart sets the right expectations with everyone and holds them accountable for decisions.
• Not defining the definition of RACI. Communicating the roles of RACI and explaining their roles is equally critical.

How to do it right? 

• Define the definition of RACI. Even if the stakeholders might feel that they might not be qualified to make decisions. Asking them to make their own decisions will drive their commitments and engagements to the project.
• Not identifying the right roles for everyone. Expecting executives to make all the decisions or executives micromanaging.
• Not communicating their roles and responsibilities so they are clear with expectations. As much is critical to define the responsibilities as is communicating the expectations.

The stakeholder matrix is like an org chart for ERP projects. It defines everyone’s roles and responsibilities and sets clear expectations, especially in resolving conflicts.

3. Requirements Matrix/Business Requirements Document

The role of the requirements matrix is to serve as an inventory of requirements, provide critical success factors, and help with system boundaries.

Why it’s important

• Inventory of the requirements in one place. This helps us quickly analyze requirements in the as-is and to-be state in one place.
• In setting the boundaries for each system. Setting boundaries for each system is critical. Without them, despite not being optimum, most companies end up assuming that ERP is the default choice.
• Identifying the right critical success factors. Not understanding which critical success factors would be critical for ERP selection may lead to false positives and negatives.

Common issues

• Not identifying the right critical success factors. Most companies end up focusing on generalized factors such as “superior user experience” or “tighter security” while ignoring the other factors that are likely to make or break implementation.
• Not defining system boundaries. The inability to define system boundaries generally leads to integration and reconciliation issues in later phases.
• Not following SMART criteria for the requirements. The requirements that don’t pass the SMART framework often carry substantial technical and financial risks, misleading the ERP selection and implementation process.

How to do it right? 

• Follow SMART criteria for capturing the requirements. Learning to be efficient with the SMART framework requires deeper expertise and years of experience.
• Don’t identify more than ten critical success factors. Focusing on more than ten critical success factors will lead to not sufficient attention to some critical success factors.

Before diving into the ERP sea, equip yourself with a requirements matrix, one of the most critical ERP selection deliverables. Sail towards success by identifying those critical success factors to steer your selection process right!

4. Business Process Re-engineering Maps

Despite the requirement matrix being detailed with clear demarcation of system boundaries, the users would still struggle to visualize their workflows. And this is where process re-engineering maps help.

Why it’s important

• Refines understanding of technical teams with as-is processes. The as-is workflows are easiest for them to understand and visualize. Drawing them helps develop a language that is easier to follow with to-be workflows. 
• Helps business users understand workflow changes and identify potential adoption risks. 
• Helps simplify processes that are going to have embedded technical and financial risks. Not simplifying the processes would lead to overengineering of newer systems, leading to adoption risks.

Common issues. 

• Not identifying the persona and developing them for each stakeholder involved. Not developing process maps from each stakeholder’s perspective may lead to lost confidence in process documentation.
• Having too much boilerplate with process maps. Having too much boilerplate might be harder to follow for business users.
• Not aligning with the enterprise software process model. Companies doing it in the DIY mode struggle to align with the enterprise software data model.

How to do it right? 

• Build at least two sets of maps, one for the technical teams and one for each user persona. The user maps are likely to be more detailed than the technical maps required for implementation.
• Build standards for process documentation. Develop and communicate the language of how to read those maps. Otherwise, users might feel motivated to use them.
• Have ERP data and process model expertise for process documentation. Hire experts with this expertise than trying in DIY mode.

Don’t forget to build the process re-engineering maps. They help uncover issues that may still be buried even with the requirements matrix.

5. Data Re-engineering Maps and Reconciliation Workflows

Data drives overengineered processes, and that, in turn, drives bloated systems. It helps unwire intertwined changes, promotes the governance processes, and helps build reconciliation flows that are likely to lead to increased admin efforts through overcomplicated reconciliation flows to cover up for simplified front-end processes.

Why it’s important

• Data drives processes, and processes drive systems. Analyze master data and figure out if that is aligned with the enterprise software data dictionary. And if not, simplify it.
• Analyzes admin efforts with new architecture or system. Without doing this, you might end up increasing admin efforts with processes.
• Sets the tone for master data governance. These changes are foundational to defining the master data workflows.

Common issues

• Data gets no attention. Most companies struggle to understand how data may drive process and system issues. 
• Data is left for technical teams. Data is very rarely analyzed during the selection issues, finding surprises in the downstream processes.
• Reconciliation flows not analyzed. Companies often make decisions based on gut feeling, leading to reconciliation and integration issues.

How to do it right? 

• Build as-is and to-be data models and align them with process models. 
• Analyze reconciliation efforts with each technical decision. Each technical decision is likely to result in a changed reconciliation workflow, so analyze them.
• Define augmentation journies of each data set. When different systems are involved, understand the augmentation journeys of each system, which one owns the data, and which ones update it.

Data, processes, and systems are connected to hips. And data is that wheel that moves them together. So don’t forget to oil your data if you want your processes and systems to work for your business.

6. Organizational Change Management Deliverables

Each change item identified might have an impact on the physical processes, which could drive the overall costs, making it harder to justify the value of digital initiatives. This is where organizational change management deliverables come to the rescue, helping you understand financial risks and adoption challenges.

Why it’s important

• Identifies the impact on the physical processes because of digital efforts. Comprehensive analysis of financial risks. This will help understand the total cost of initiatives.
• Avoid losing investments in initiatives with adoption risks. The lack of adoption may lead to losing investment completely.

Common issues

• Change items not formally documented. Companies that don’t understand the importance of change management struggle to formally capture the changes.
• The cost of changes is not analyzed completely. Tracking change management items but not accounting for their costs in the decision-making of digital initiatives.
• The timeline of changes is not aligned with all the changes. Not aligning project plans of change items may lead to scheduling and budget issues with digital initiatives.

How to do it right? 

• Build a project plan for each change item. And align it with the digital plan.
• Perform TCO analysis of each change item comprehensively. The total cost must include the cost of each change, including its implications.
• Don’t build or sign contracts without getting buy-in on each change item. Signing software contracts without understanding the cost of each change might eat up cost savings procured through software contracts.

The change items have their own lifecycles and require analyzing costs in conjunction with digital initiatives. So make sure you are not treating them as training items that generally get attention at the last minute.

7. Transformation Roadmap and Business Case

The roadmap would dig into one of the initiatives based on the business case and takes a much deeper dive of the agreed solution. And if the main path may turn out to be more expensive than originally planned, alternate plans may be explored.

Why it’s important

• Helps create a comprehensive business case for each solution. Before ignoring any solution, understand their business case.
• Helps avoid financial and technical risks with the approaches. The business case would avoid the financial and technical risks embedded with each solution.

Common issues

• Roadmap does not include the cost of change management. Not including the cost of change management might lead to a biased financial analysis.
• Changes are not communicated with the stakeholders who might influence the adoption of change. Not communicating changes with the stakeholders might lead to adoption risks and financial surprises in the downstream processes.
• Business cases assume too many technical risks. Not enough due diligence of the business case might include financial and technical risks, leading to biased decision-making.

How to do it right? 

• Assess the transformation roadmap comprehensively. Don’t leave any stones unturned with the roadmap.
• Due diligence to remove technical risks. Perform enough due diligence to understand the risks before implementation or signing contracts.
• Involve users whose influence may lead to adoption or financial risks. Don’t ignore users who might influence the change.

The transformation roadmap and business case help select the right solution that is most technically feasible and with the least financial risks.

8. Enterprise Architecture and Master Data Governance Plan

Once a solution is selected based on the business case, the enterprise architecture and master data steps help in digging into the solution further and building technical specs in agreement with the technical teams.

Why it’s important

• Defines the roles and responsibilities of each system. Technical analysis with roles and responsibilities is equally important as business analysis.
• Defines their interaction flows. The interaction flow helps in understanding how each system would communicate and the data they will share among themselves.
• Defines the master data governance flows across the system boundaries. Just like reconciliation flow is from a business perspective, master data governance flow is from a technical perspective and is equally important.

Common issues

• Typically delayed for the implementation phase. Companies not as savvy with technical skills believe that managing master data is the technical teams’ responsibility.
• Not detailed enough to be meaningful for the technical teams. Companies with limited implementation and technical background might not be detailed enough for it to be meaningful for technical teams.
• Misalignment between technical and business perspectives. The technical teams might not have enough business background, and the business might not have enough technical background, leading to misalignment.

How to do it right? 

• Do it in the prep phase. Doing it in the prep phase will help you uncover technical and financial risks commonly responsible for going over budget with digital transformation projects.
• Get agreement from technical teams. Involve technical teams during the selection phase and get their buy-in on the solution.
• Define master data governance flows from the technical perspective. And don’t wait for the implementation phase to do that.

Enterprise architecture and master data governance analysis must be done in the prep to uncover technical and financial risks, generally discovered during an implementation phase.

9. Solution Matrix, Vendor RFP, and Demo Scripts

The role of the solution matrix, vendor RFP, and demo scripts is to provide a framework for the selection process. Without a framework, most solutions might appear similar and confusing.

Why it’s important

• Reduces the amount of time with vendor briefings. Documenting details helps reduce time with vendor and team briefings.
• Provides a quantitative framework to select the right system. Having access to a quantitative framework leads to teams being confident with a solution and owning it. 
• Provides structure for vendor demos and streamlines the selection process. Creates a fair process for vendors and sets the right expectations on the critical success factors. 

Common issues

• Writing too much boilerplate with RFPs. Companies that write too much boilerplate with RFPs run the risk of frightening seasoned vendors as they are likely to be sensitive to their time.
• Not identifying the right critical success factors to compare solutions, which would generally mislead the selection process.
• Demo scenarios are not captured with the right depth. The superficial demo scenarios generally lead to vendors brushing off the critical ones.

How to do it right? 

• Have the right balance of detail with the RFP. The RFP needs to have the right level of detail for vendors to find it credible.
• Get buy-in on the framework. The team needs to agree on the framework for how you plan to evaluate different solutions.
• Align expectations of the demo with each party. Align team members to the demo script, or the most vocal team members are likely to hijack the demo. 

Make sure you have a framework for your ERP selection, including these ERP selection deliverables, but don’t forget to align your teams on the framework for it to be effective.

10. Contract Analysis and Vendor Score Cards

The role of contract analysis is to identify the red flags with the contract based on the agreed architecture and solution, whereas the purpose of vendor scorecards is to rank each vendor based on the learnings during the demo.

Why it’s important

• Uncovers hidden risks embedded with contracts. Identify risks such as overage charges, storage and bandwidth limits, tier structure, and user license limitations.
• Aligns implementation with licensing. Helps remove any financial surprises because of misalignment in the licensing and implementation plan.
• Provides a framework to compare vendors. To have an unbiased comparison.

Common issues

• Not hiring software contract experts for analysis. Mastering contracts takes years and requires deeper expertise in architecture and legal.
• Not creating a framework to compare vendors. Without having a framework to compare vendors, the team might make decisions based on superficial factors.
• Signing contracts before understanding fine lines. Signing a contract without understanding the fine lines might eat up all your discounts.

How to do it right? 

• Understand contract variables and how they impact the TCO. And not just at the surface level.
• Align licensing with the implementation plan. The licensing access must be compliant with the implementation plan or expect financial risks in the later phases. 

Don’t underestimate the expertise required to interpret software contracts. Without it, you might be sitting on financial and legal risks that will fire back in ways you might not expect.

Final Words

Not defining deliverables for your ERP selection is like running without a finish line. And that’s probably the reason why companies struggle to understand the importance of the ERP selection phase. Once you set the expectations on ERP selection deliverables, the ERP selection phase will make a lot more sense. 

It will also help your executives understand why it exists and why they should be investing in it. But most importantly, ERP selection isn’t just about reading brochures and making life hard for implementation companies!

FAQs