When building business applications, Supplier Relationship Management (SRM) is one of the important business functions that is often overlooked by application product managers providing software solutions to specific vertical industries. Either SRM gets crushed under the weight of heavy supply chain focused logistical processes or it gets oversimplified by vertically focused ERP systems that simply track vendors and suppliers in the address book and keep track of purchase orders and accounts payable. As a result, rich, usable procurement system features are frequently not available to those involved in the requisition and purchasing process. But it should be clear that vertical industries are not only unique in the ways that they manufacture and sell, they are also unique in the ways that they consume. And more importantly, great efficiencies and cost savings can be built into your software by paying careful attention to the proper design of supplier and purchasing related business processes.
ERP systems tend to squeeze a few purchasing related features into what they will call the “source-to-pay process.” To meet the needs of purchasing managers and others involved in the process, an add-on package for SRM is made available that interacts with the back-end ERP. But what functionality should you include in a uniPaaS application designed to meet customer needs for SRM? I believe a good software product manager needs to ask the right questions in order to create a good solution. Here are a few ideas:
Understand the Business Need. Is the organization a manufacturer driven by a supply chain mentality? In this type of organization, the purchasing process is viewed as an input into the supply chain, work-in-process is viewed as a natural part of the manufacturing or shop floor operations, and finished goods delivery is viewed as the output of the supply chain process. Demand forecasting, optimal inventory levels and logistical considerations such as just-in-time delivery will be paramount to achieving organizational efficiency. Other organizations tend to be more adhoc in their purchasing processes with less predictable relationships between demand forecasts and the specific types of requisitions that will follow. Large service organizations for example, will tend to have more variation in purchases with less predictable inputs and outputs. But this does not mean that purchasing officers do not need automation. Concerns here tend to be in identifying which supplier relationships are most in need of improvement. Should bulk purchase agreements be considered? Should contracts be setup or is the purchase pattern not likely to repeat. How can the software you create begin to categorize and recognize purchasing patterns in order to identify potential efficiencies?
Security, Role Based Access Control, and Management. Who are the users of the system? What are their user rights and responsibilities? How is information archived and preserved? Who can view the information? Who can initiate a process, modify it, approve it, and confirm that it took place and that goods were received and used for the intended purpose? How will those responsible for spending/requesting, budgeting and managing/approving be able to see reports, KPI’s, dashboard views and access their tasks or “To Dos” in the purchasing/requisition processes? Have needed alarms, alerts and escalations been built into the process? Will users be able to access the system over the Web and on handheld devices?
Requisitioning. Create a clear requisition process. Too many companies jump straight to a purchase order process. A PO is submitted and approved without a separate internal requisition request process. In larger organizations, the functions are clearly separated. Approval processes and workflow need to be automated. Does the system handle proxy approvals when the primary approver is not available? Are there acceptable substitutes for the materials requisitioned? What constitutes “comparable goods”? Is there a legitimate need for sole source items? What alternate processes are needed for capital expenditures or unbudgeted items?
Order Management. Once a requisition is approved, orders need to be generated. Can similar requisitions be combined into one order? What quantities should be ordered for maximum economic efficiency? Should a replenishment point be established? What is the ideal inventory turn? Will EDI processes be used? Are some POs communicated verbally, by email, FAX, postal mail? What about the increasing number of orders placed via websites? Is there a method in place for tracking the numerous legal agreements being executed via the web? How are sources of supply identified and matched to requisitions? Are Google-like searches and fuzzy searches available to help source the correct supplier? Are multiple vendor quotes (bids) required? Are the effectiveness of negotiations tracked? How are the actual orders generated and tracked? What are the requirements for recurring orders? How many layers of approval are required? Are procedures needed for internal sourcing and inter-company transactions?
Receiving and Settlement. Are suppliers meeting their delivery deadlines and promises? Are concessions offered being delivered? What triggers the payment process and settlement. How are invoices received matched to orders placed? How are returns and claims handled? Can unused materials be returned? What is the business rule for such returns? Do processes need to be identified for matching purchases to specific projects, departmental budgets, or customer accounts? Are expenses being passed on to customers directly or marked up? Are costs being properly tracked and reflected in COGS? What requirements are there for multi-currency? Are interfaces needed for international tariffs and customs? How will you account for drop shipments? Are proper invoicing triggers in place for drop shipments? How are shipping methods compared and costs evaluated and tracked?
Satisfaction Management. Were the internal customers satisfied with the products or services delivered? Did the materials pass inspection and testing? If not, what remediation steps are required and how are these tracked? Is there a grading system for suppliers? Are order histories easily accessible? Can vendors be easily compared? Are their market prices involved that can be used for comparison?
Contractual Management. Often contractual relationships need to be assessed at a higher level than that of individual orders? Are quantity commitments and discounts being met? Is there an orderly methodology for tracking terms and conditions? When should an agreement be on your paper versus the vendors’ paper?
Master Data Management and Disambiguation. Resale organizations have huge problems around master product data management. Efficiencies can be achieved and sales can be increased simply by having the right information. Product numbers, names and descriptions frequently change for identical or nearly identical items. Failure to recognize same or similar items can result in lost sales, overstocking and other problems. Multiple units of measure may also be applied to the same goods. How are these differences best reconciled?
Conclusion.
Every industry is unique and the software product manager designing applications for a specific industry can create use case interviews and surveys to help identify the purchasing and requisition patterns that need to be built into the supplier relationship management you build with the uniPaaS application platform.
No comments:
Post a Comment