Org.A Purchasing & IT Departments Log excerpts. Year 1999-2002:
A significant new focus area that has been focal point for global corporations is the automation of purchasing processes for procurement of indirect (MRO) and direct goods and services. A strong belief exists that there are fundamental differences in the two oft-misused terms – marketplaces and exchanges – Marketplaces would be for systematic sourcing and Exchanges would be for spot buys. Organizations, if they are to move up the value chain, organizations, need to face the reality that if they are to succeed, they have to build a private model with a thick network of business partners. Building business processes is the key. Most of the System Integrators made their money in setting up e-marketplaces and exchanges based on impractical revenue models. E-Procurement solutions are meant to corroborate as an optimal investment, not to replace existing business models and processes at a higher cost. With the initial euphoria surrounding B2b slowly dying out, reality is finally setting in. A shakeout is happening and Org.As landscape needs to change ASAP
Org.A Purchasing & IT Departments Log excerpts. Year 2003-2004:
Best-of-breed E-Procurement solutions cannot accelerate ROIs or streamline purchasing. The fitment doesnt match to a T. Maintenance, Rollouts and backend integration is where Org.A should be looking at leading to giving way to a new paradigm of an extended enterprise where the focus would invariably shift to streamlined sourcing alone. Going-Live is not staying alive. We understand this fact and our value propositions to our valued customers are based on this. With E-Business ventures focusing on Business models and becoming more vendor agnostic, the need exists for a new business platform that would help us, Org.A, to do away with the heavy dependence that we have today with the Ariba Spend Management Solution, starting off with TRADEX and Trading Dynamics. Controlled MRO spend needing to be regulated via catalogs with an Ariba Buyer solution, depending heavily on the Ariba Commerce Services Network (now ASN), Category Management, Analysis etc. etc. would have to be done away with in the long run if Org.A is to streamline its landscape and lower TCO with a singular platform. It is the best-of-breed solutions like Ariba Buyer that have spawned off a need for middleware like TIBCO in the picture. A case must be defined to retire these applications to lower TCO. The quest has to begin for a new robust landscape with SAP. The quest must begin for a spend management suite that addresses the need for xPRO .and a middle path MUST be found between Ariba Spend Management Suite and mySAP SRM This is not the way we want Org.As DNA to grow ..
A Middle path – The quest for xPRO: Year 2005-2007:
A custom e-procurement composite that is scalable to a sourcing and e-marketplace solution is needed to streamline purchasing needs and reducing spend to arrive at a greater degree of acceptability in the purchasing community by building in best practices in purchasing and doing away with functionality that increases costs and dependence on a vendor. Be it Ariba, be it SAP. Ariba Spend Management Suite has to be retired from the landscape, but a better solution needs to be arrived at. Org.A. SRM has been evaluated but the fitment needs are more custom.Comparison pales when one does it between Ariba Buyer and erstwhile Commerce One. The functionality match has to increase to address the key business process issues. The need of the hour is to simplify the landscape in tune with SAPs ESA roadmap, but with a better business fitment.
The Catalogue Management tool dilemma:
CCM. BugsEye. Requisite. MDM(xCAT). So on and so forth. Why cannot a singular catalogue tool be propagated by SAP? Why should Org.A be looking at different versions of SRM and catalogue tools at all? Would it be a better alternative to decide on a cataloguing tool within Org.A itself that spans across different requirements within its overall landscape? Once that is done, why cannot Org.A look at a composite that does away with the need of externally hosted catalogues and paying a bomb for the usage of a network that is not cost-effective? Why does Org.A need to pay for additional functionality like P-Cards, which are nice to have given the context of Org.A? Does a swing from Ariba SM to mySAP SRM make sense at all? Why not a middle-path composite? Enter xPRO.
The Catalogue Management tool decision :
Doing away with an e-procurement best-of-breed application for Org.A, who is reluctant to go for the full mySAP SRM suite. Only a standard cataloguing tool is required. It could be any one. It makes sense even if ASM becomes powered by NetWeaver. And if xPRO can be made agnostic of the cataloguing tool while Org.A freezes its decision with MDM, it would provide Org.A with the necessary business ballast to standardize MDM across the board for all its cataloguing needs and retiring Requisite/BugsEye/CCM and the like, including a storefront, a auction engine that goes Dutch, forward, reverse, Japanese….any which way Org.A wants it to go. Probably, it could now resurrect its B2B ideas for dumping excess stock. It is Org.As belief that SAP AG will go this route as well with the cataloguing tool decision. xPRO must be agnostic of the catalogue tool in its fold. Showcase the same with MDM 5.4 SP3 and explore a business need for MDM as well. GDS initiatives can wait.
Sample business reasons to retire Ariba Spend Management Suite from Org.As landscape:
Business Issue #1:
A third party fax needed or a middleware needed for communicating with external business entities or increase costs with ASN communication?
Thought: Clutters the landscape or is expensive or is a vendor sticky solution. Check.
Business Issue #2:
Big issue in handling Purchase Order changes; unnecessary technical loops and hoops to circumvent this issue.
Thought: There can never be a seamless solution with SAP Integration for PO changes. If there will be one, it will be a technology blockbuster with matching costs. Ariba Buyer 8.x upgrades will raise costs as well.
Business Issue #3:
Items available as catalog items being requisitioned as ad hoc requisitions at a higher cost. The idea is to save costs by streamlining indirect purchasing, not automating inefficient and redundant processes. Why not get Ariba Contracts in the picture?
Thought: A long as the corporate decision is to buy licenses for every problem as a separate module created by the vendor, Sure. Why not?
Business Issue #4:
Fixed assets/capital asset MRO purchases linked to projects, no way any standard application can handle this. Customize the applications along with custom BAPIs at the R/3 side to make things work.
Thought: Investing in a best-of-breed applications and investing in complex customizations including new integration events and R/3 objects? Is Org.A on the right track?
Business Issue #5:
Catalog searches take a very long time to execute, making the requisitioning process an arduous one.
Thought: Invest in arduous catalogue management in Ariba Buyer. Also invest in other catalogue management tools within the SAP Landscape. Hold on, does requisite sound familiar?
Business Issue #6:
Since ORGA is not implementing the P-Card process now, they have a few P-Card suppliers and their reconciliation is to be handled manually on a month-to-month basis outside the system. Of course, there is a choice in moving ahead with a state-of-art Invoice settlement solution with Ariba and Amex.
Thought: Are we using a spend management solution to reduce corporate spend or spend on the vendor through the same solution? Probably using P-Cards?
Business Issue #7:
There is absolutely no way to monitor spending across various cost centers and put a cap to streamline processes around allocation usage to help curb spending. If ORGA is to monitor costs based on cost centers and have a cap on their budgets, ORGA cannot do that with the existing application functionality. Reports are rudimentary and manual.
Thought: Need to invest in a budgeting solution/customization? Has Org.A ever contemplated the need for Ariba Analysis, category management and a master data solution to manage a cluttered master data syndrome within its own best-of-breed landscape? This gets murkier and murkier
Business Issue #8:
Allow the vendors to select and process their invoices over the extranet on their own.
Thought: Sure, shouldnt we be doing this through an EFP with SAP Enterprise Portals? After acknowledgement by Accounts Payable staff, allow SAP and non-SAP users to access their own invoices and approve them. Allow AP users to retrieve the invoices from one screen? Are we duplicating efforts here chasing the end of the MRO spend rainbow?
Business Issue #9:
ORGA imports commodities from ORGB, ORGC, and other business partners from different geographical boundaries, to be re-sold in the US market. Can ORGA have a streamlined process custom built around it? Right now, all work is manual.
Thought: More costly customizations, outside of the SAP landscape.
Business Issue #10:
Catalog management becoming too huge to be monitored and maintained with delays in new price lists from suppliers like Boise, Mutual Engraving, etc. Decision makers became too myopic with application capabilities, enhancements, and third-party applications.
Thought: Isnt it time even Org.A thought about a standardized cataloguing solution? And shouldnt SAP be doing so as well?
Business Issue #11:
In any approval hierarchy for a requisition, one has approvers and watchers. An approver can be a watcher in some cases, and vice versa. Opening each and every purchase requisition in my inbox, after logging in, does not tell you whether you are an approver or a watcher. The application didnt support this. And valuable time of key approvers was spent on clicking and understanding their role in the PR process. This is an application limitation.
Thought: Maybe Ariba would bring/brought this on as a feature when it saw one of Org.As SIs doing it at a customer site. But this is a huge technical enhancement that entails cost as well.
Business Issue #12:
ORGA has a six accounting segment structure, some combinations may be valid and existing, some may be valid and non-existent, while others may be invalid. If there is no accounting segment validation happening in the eProcurement application, many purchase orders will not be reflected in the underlying SAP R/3 application. These purchase orders, though sent to the suppliers as fax or EDI, cannot be pushed into the underlying SAP R/3 leading to a situation where you have invoices coming in, but no purchase orders to settle against in SAP R/3.
Thought: This is best done in R/3. Hang on, if Org.A is doing so much of customization in R/3, isnt something wrong with the CIO vision?
Business Issue #13:
During a product requisitioning cycle, a requisitioner can receive goods, or central receiving can do the same. This leads to effort duplication; one receives, the other approves. With services (which form 57% of all requisitions in ORGA), it is the other way round. Business needs dictated central receiving to receive all goods in the dockyard, and the requisitioner to receive all services. There was no need for a receipt approval.
Thought: Simple, customize the receiving rules. Slight problem customizing rules isnt so common a task and takes time and resources.
Business Issue #14:
Consumption orders; intra-company orders on MRO items, how can ORGA automate this process flow?
Thought: Simple, customize and spend through Ariba itself as a service item on the SI work done.
Business Issue #15:
ORGA purchases chemical items as well under this category, and there is no automated process within the existing application to capture and validate their toxicity numbers from the Dangerous Goods Regulations (DGR) list. The toxicity number is required for declaration purposes. How do we ensure that all chemical items that are requisitioned have a toxicity number?
Thought: One guess!
The Ariba-SRM dilemma:
Query 1: What if Ariba Spend Management Suite is to be powered by SAP NetWeaver and be converted into a custom composite leveraging ESA?
Ans. Right. This would only spiral the cost, surely it wouldnt come down. TCO remains constant, if it doesnt increase. So, are we talking esoteric over here? Surely, a brilliant technical solution. (But, one would still buy reams of paper through that and now at a higher cost)
Query 2: Agreed, we have to do away with Ariba Spend Management Suite shortly, and we have committed ourselves to an SAP roadmap with SAP NetWeaver and ESA. So why xPRO and not SRM?
Ans. SRM is the right choice to go with if you require the kind of functionalities like Punch-Out for your suppliers and all your buyers across the globe are well connected electronically to leverage ASN as well with SRM in the future. Yes, if you streamline a lot of spend through P-Cards as well. But, what if, Org.As need is to have a no-frills-attached spend management solution with MDM or any other cataloguing tool at the center leveraging ESA and implemented as a composite at 1/4th the cost? Isnt that what lowering TCO about? An application that leverages your core R/3 (or ECC) engine, your BW instance, your SAP NetWeaver platform?
In the Architects World, xPRO is a balanced middle path built with CAF 7.0 leveraging the SAP NetWeaver platform in any SAP landscape agnostic of the cataloguing tool as the central component, aligned with SAP, aligned with Org.As ESA roadmap.
Functionality Quick-check of xPRO :
Not in scope
1. Punch-Out catalogs
Sample Business Logic / Functionality to be developed in xPRO:
– Requisition create based on dollar limits
– Approval generation based on configured rules
– GP driven customizable approval process/scalable for use with an existing workflow engine (optional)
– Ad-Hoc requisitions capturing additional details for business justification based on commodity code
– Prevent users from creating Ad-hoc requisitions for catalog items
– Shipment track and trace
– Approval process for Supplier catalog maintenance
– Custom reporting using BEx query iViews for purchasing
– Supplier maintenance through e-form process
– EFP based Catalog maintenance
Outro – The New Rules of the game:
As the initial euphoria, organizations will focus more and more on their core-competencies, redefine business processes to redefine their supply-chain, look at Partners for innovative and out-of-the-box ideas to better their current systems with minimal cost impact. CAF is the new paradigm of development and borders between customization and standards. Customers like Org.A need to explore innovative solutions around the same to develop composites of their own along with their SIs if they are to avoid a new breed of best-of-breed players with composites or NetWeaver powered applications. Delta functionality and business fitment with innovative solutions within the customer community will drive the new market with SAP NetWeaver. And Fusion.
And Organizations like Org.A will rule the roost in the Architects World.