Cost Reductions in the World of SAP, EDI and B2B Integration Services

Today nearly all Business Managers are working without experience. They have never experienced the challenges and difficulties that they face today in the world markets. These are uncertain times. Much about the economy and the market climates are unknown, but there are some things that we can know and use to make decisions.

1. Companies must reduce operational costs as sales are shrinking
2. Companies must become more efficient at each task and process
3. Companies must learn to operate with fewer FTEs (full time equivalents)
4. Companies must consolidate operations and systems to lower costs
5. Companies must standardize systems and processes to reduce complexity which causes higher TCO (total cost of ownership), support and maintenance costs
6. Companies must inventory internal systems to maximize their use and therefore their original ROI
7. Companies must shed non-core operations to reduce costs and increase staffing flexibility
8. Companies must focus their brightest minds on core value and competitive advantage processes and projects. With fewer FTEs, brain power must be focused on what will enable the company to survive and prosper, not on mundane and routine non-core operational issues
9. Companies must focus on improving cash management - reducing DSO, recognizing early payment discounts from suppliers, reducing inventory, reducing transportation costs through better management visibility, etc.

In these uncertain times - we can be certain that the items listed above will help.

My background and expertise is in the areas of business process automation through B2B and EDI means. Keeping the above list in mind, here are ways companies are trying to address the above issues in the realm of EDI and B2B:

1. Many of the world's largest companies are now using managed services companies, B2B exchanges and EDI hubs to operate some or all of their EDI and B2B operations for less costs than operating it in-house. Companies certainly need their ERP system to send and receive electronic data interchanges (EDI) or other B2B electronic files (flat file, XML, CSV, etc.) with their customers and suppliers, but once the processes and integrations are understood internally they believe they can use managed services more efficiently and for less costs by sharing the effort with other exchange or hub members.
2. Staff Reallocation: Your internal EDI teams are often some of the most experienced and knowledgeable people in your IT department on the subjects of business process automation. Their skills and knowledge are often better focused on designing and supporting new business processes that provide competitive advantages, rather than in EDI mapping, maintenance, support and operational roles. The majority of effort spent operating and supporting an EDI system offers no competitive or strategic advantages. The value comes from ramping up EDI implementations that can reduce admin costs, increase supply chain visibility, reduce invoice processing costs and enable business process automation. Again, the value is not in the maintenance, support and operations, but in the implementations of new business processes and trading partners that will help the company's bottom line. If an EDI and B2B department could spend 90% of their time on-boarding new business processes and trading partners then the company would be maximizing the value of EDI and B2B. If an EDI team is spending 90% of their time in EDI support, maintenance and operations then the company is not recognizing the value and getting the optimal ROI from their efforts and limited resources.
3. B2B Hubs and EDI Exchanges: Take advantage of other companies' work and investment. There are EDI managed services providers that already have tens of thousands of companies connected to their EDI exchanges. By connecting once to the B2B exchange or EDI hub, you can often access thousands of pre-defined and pre-configured EDI messages. Find ways to save money by reusing the hard work and investment others have already made.
4. Greater ROIs: Your best EDI staff should be focused on automating more business processes so there is a greater ROI on EDI and B2B services. So often companies only automate EDI and B2B communications with less than 10-15% of their trading partners which minimizes the ROI not maximizes it. Focus on automating the other 85-90%. Extending automated business processes to larger numbers of your customers and suppliers where there are easy, obvious and understood ROIs and efficiency gains.
5. SAP Strategic Alignment and consolidation: If you are an SAP customer, consider aligning your EDI and B2B strategies with SAP's EDI and B2B strategy for Netweaver PI. Understand their strategy and Netweaver EDI and B2B road map and ensure your strategy takes advantage of your investments in SAP. SAP has been developing and is now implementing some very interesting EDI and B2B solutions through SAP BPO partners using their Enterprise Services Repository, Netweaver PI and Global Data Types to change the paradigm about how EDI and B2B is implemented. Ride the coat tails of SAP's investment and strategy. If you use SAP it would be important to understand this strategy and how it might benefit you.
6. Core Competencies and Processes: Invest in your core competencies and processes (manufacturing, R&D, distribution, sales, marketing, services, etc) that provide survival and a competitive advantage. Today companies are choosing to outsource non-core tasks and processes to call centers, phone utilities, water utilities, waste water utilities, Internet providers, electrical utilities, etc, because they offer a higher quality service for less money than operating it internally. EDI and B2B is now available in a less expensive and more reliable utility model as well through many EDI hubs and B2B exchanges.
7. Consolidations: Many companies have multiple ERPs and multiple EDI systems in different divisions and in different geographical areas. Often these are redundant systems brought into the organization through mergers and acquisitions. The concept of an EDI Shared Services Center has relevance here. For the same reasons consolidating multiple instances of SAP and other ERPs to the fewest instances possible makes sense, likewise reducing the number of EDI systems to as few as possible also makes sense. The reasons are reduced costs, consolidated expertise, better management visibility and standardized integration strategies.
8. Agility: Companies must be able to move fast and change paradigms as new markets open or close, supply chains expand or contract and the economy grows or shrinks. The more inflexible a company is, the more difficult it is to keep up with these rapid and unpredictable changes. In today's economy, inflexibility equals vulnerability to market conditions. Flexibility comes from the ability to act fast. Often when it comes to operational issues, acting fast means being able to contract for services to accomplish a near term objective. Having an EDI and B2B strategy and system in place that allows either an in-house effort, or a contracted managed service approach gives the company the maximum flexibility to grow or contract based upon market conditions.

****************************************
Kevin Benedict
http://www.linkedin.com/in/kevinbenedict

EDI Standards and Intellectual Assets in a Slow Economy

Often, when people think about EDI/B2B standards, they think of decades old technologies, file formats and communication protocols. This has some truth, but the real value of EDI/B2B standards is not in the technology and formats, but in the intellectual assets represented in the content of the standards. Often file formats can be developed over a few months, but the content in the EDI standards often takes decades of detailed research and analysis to define, develop and codify.

I have had the opportunity to participate in many industry EDI standards meetings where the details of an EDI Transaction Set were discussed. The process never ceased to impress me. EDI experts often know more about a business process than just about any other position in the company. Why? They must understand exactly what business data is needed, where it comes from, where it needs to go, and how it will be used. They must understand each step in the work flow to understand how business data can be moved, approved and reviewed. They are often involved in the process of creating new business processes to meet the requirement of a customer. They must understand how the data is entered into the system, what database stores the data, who owns the data and what the data means in the context of the business process.

Often the experienced EDI expert also knows what other customers use similar EDI transactions, what is similar and what is different about the data requirements of the different business units, divisions and geographical areas. This knowledge is an extremely valuable institutional asset and must be recognized and protected.

It is very easy and common in large companies to forget about the intellectual assets in a company. "Re-creating knowledge that a company already possesses is a time and resource consuming activity," writes author Thomas Gale in the white paper titled Reusing Intellectual Assets. "As companies increasingly compete on the basis of knowledge, they must improve their methods for reusing intellectual assets." EDI experts are often one of the richest sources of intellectual assets in the entire company.

It would be a wise strategy to have a database application that served as an EDI repository and registry for all information related to a trading partners and their EDI messages and content requirements, but it is very rare for an enterprise to have the foresight and resources to build this repository. Today, these tools are mostly found in EDI managed services companies. They have the volume and business model to support tool development and strategy execution. For companies that do not have these internal resources, think 2 or 3 or 4 times before laying-off your experienced, EDI experts. The intellectual assets inside their heads take many years to replace.

EDI experts are not just communication and format specialists, rather true EDI experts understand not just the syntax of an EDI file, but the content and semantics of the content and how it is used. If a company must reduce the size of their IT and EDI departments due to economic issues, think about outsourcing the EDI operations to a professional EDI/B2B managed services business, but keep the EDI experts in-house as their knowledge is critical and very useful in the areas of business process design, supply chain management, logistics, orders-to- cash, procure-to-pay just to name a few. They often make exceptional business analysts, systems analysis and customer IT liaisons.

****************************************
Kevin Benedict
http://www.linkedin.com/in/kevinbenedict

SAP and Supporting Extended Supply Chains in a Complex World

In an article by Scott R. Sykes, Principal of Supply Chain Solutions at SAP America, titled Understanding and Managing Supply Chain Risks, he writes about companies taking greater risks now days with increasingly complex and extended supply chains. Sykes describes them as follows, "Supply chains today are growing continuously more complex, interconnected, and global..." He identifies some of the issues that are the result of this trend:

• operations become increasingly dispersed
• longer lead times are required
• complexity increases
• regulatory and compliance issues increase

Extended, growing and geographically dispersed supply chains with increasing numbers of participants require a completely different way of communicating B2B and EDI(business-to-business). Traditional ways of communication involved long, complex and costly EDI implementations that often took months or years to set-up. It was hard enough when you had a handful of supply chain participants, but as supply chains become moving targets with thousands of long-term and short-term suppliers different strategies must be implemented to reduce both risk and chaos.

In most companies that I work with, the EDI department cannot keep up with the current work demand. The IT budgets are decreasing, while the need for communicating with a fast growing supply chain is increasing. Traditional EDI simply takes too long to implement, requires too many EDI staff members, and does not provide a quick enough ROI. The business demands faster responses from the EDI team to keep up with the fast growing supply chain and new "best practices" for keeping a lean production system. The pressure this puts on the EDI team makes for an unsustainable work environment and one that cannot meet the conditions demanded by the business. There needs to be a new paradigm.

The complexity that fast growing and extended supply chains involves is worth reviewing in more detail. Here are some of the issues that impact extended supply chains as detailed by Sykes:

• fluctuations in customer demand
• currency exchange rates
• market pressures
• environmental factors
• geopolitical factors
• weather issues
• natural disasters
• political instability
• union action
• financial factors
• piracy (I added this)

These are all risks and complexity separate from the complexity involved with the B2B/EDI system, but I wanted to highlight all of them to give us a full picture. With the above listed issues, you don't want the EDI and B2B system to be unavailable, unreliable or inadequate. A company needs B2B and EDI communications with all new supply chain partners to be automatic and on-demand in order to reduce or manage the issues listed above. Can you image managing all of the above factors via paper, voice, email and fax?

The complexity discussed above was in the context of your first level suppliers. Your suppliers have suppliers, and they have suppliers. This is a systemic issue, not just yours. There needs to be a macro-view of this complex issue. SAP is working on these issues at a macro-level now. Many of their recent executive interviews, investments and announcements have been related to the need to put in place an SAP centric solution for helping supply chains "interconnect" in a new paradigm. The new paradigm involves the Enterprise Services Repository and Registry, Netweaver PI, Global Data Types and managed EDI/B2B services for SAP users.

Companies need to either figure out how to ensure that the EDI/B2B quality of service required by the business exists internally or find an EDI/B2B managed services company that can provide this capability. It is rare for a company to be able to support an EDI/B2B team sufficiently to meet the business demand for their services when there is a large, fast growing and extended supply chain involved. Internal EDI/B2B departments have great difficulty achieving economies of scale on their own, so they often lack the tools, methodologies and industry expertise needed to provide a high quality service.

Kevin Benedict,
www.b2b360.com
http://www.linkedin.com/in/kevinbenedict

SAP Business Network Transformation, UDDI, EDI and Enterprise Services Repository

Traditional EDI/B2B strategies, methodologies and systems are quickly on their way out for SAP users in 2009. Why? A huge amount of the complexity that traditional EDI environments required will be removed by SAP. SAP users will be able to re-think and reallocate many of the resources and budgets that have been assigned to supporting EDI and B2B related integration projects in the past. What is making this revolution possible? A maturing group of standards that are being brought together in SAP’s Netweaver PI and the Enterprise Services Repository and Registry to hide and eliminate the traditional complexity involved in the implementation of B2B/EDI and integration projects. Here is a list of a few of the standards involved:

• UDDI
• WSDL
• Web Services
• Enterprise Services Repositories and Registries
• Executable Business Processes (BPEL)
• Global Data Types (GDTs)
• Service Oriented Architecture (SOA)

For decades SAP has been focused on developing business solutions that work together to form one large homogeneous ERP solution. Much of this goal has been accomplished and they now seem to be focusing significant amounts of attention on the next frontier - making one large homogeneous “business network.” This involves making it easier for their solutions to speak to the world. SAP solutions are fueled by business data. SAP solutions both produce and consume business data. The data required is not all self-generated. Much of the business data is produced by external business network participants (trading partners) in the form of Purchase Orders and Invoices (These are just two examples of thousands of different business documents that are exchanged between business network participants).

Over the last decade we have all witnessed the transformation of SAP solutions from many disparate components, to an integrated system based upon a defined set of standards and technologies (e.g. SOA). The process of transforming a trading partner community into a homogeneous business network will follow a similar path. Utilize a defined set of standards and technologies and organize them in a manner that can be cost effectively implemented in a reliable and seamless manner.

The obstacle to a homogeneous business network in the past was a lack of defined standards, strategies and methodologies for bringing it all together – chaos reigned! The Enterprise Application Integration (EAI) market thrived for many years on chaos. The lack of standardized integration strategies and technologies provided an opportunity for third party EAI software vendors to introduce different integration standards and strategies into IT environments that lacked them. This is very similar to the EDI translator software industry. They thrive on chaos, but won’t survive, in their present form, if companies like SAP bring order to the chaos. SAP appears to be investing significant resources to bringing order to EDI/B2B in 2009.

EDI traditionally involved the following:

• Understand what business data needs to be exchanged with a particular business partner
• Determine how it can be sent and received
• Find an EDI standard that is a close match
• Document the EDI standard and subset of the standard that will be used
• Find out where the data is stored (business application database)
• Develop a strategy for exporting and importing the data from the database
• Decide on a communication protocol for sending and receiving
• Automate the process
• Test, Test, Test
• Start over again with the next business partner and business document exchange

This is about as inefficient as one could possibly make it. From SAP’s central and influential position, they can pre-define and standardize most of these steps and greatly simplify implementations. It will be fascinating to watch this evolve in the Enterprise Services Repository and Netweaver PI environments. Once EDI messages and processes are pre-defined as services, they can be available without big and expensive integration efforts and multi-year EDI implementations.

If most EDI and B2B processes become pre-defined services in SAP, the workload for traditional EDI departments and IT developers involved in integration projects will be significantly reduced. EDI departments will no longer be spending significant amounts of time on integration projects, but rather on supporting the data format needs of external business partners. This is not a core strength or competitive advantage kind of effort. It is simply matching and supporting data formats and their semantics and syntaxes. I expect companies will look to outsource this remaining work to specialized managed services companies that focus on aligning data formats for entire business networks where economies of scale and efficiencies can be achieved.

****************************************
Kevin Benedict,
www.b2b360.com
http://www.linkedin.com/in/kevinbenedict

Who in a Company Needs EDI and B2B?

I remember the shock when I learned that our company had 4 different EDI/B2B systems. Why was I shocked? I was the IT department's EDI Manager, and up to that point I only knew of 1 system. How could I, the EDI Manager, not know we had three other EDI systems in the company? Let me tell you why.

1. The Government Sales team had a desktop EDI system to receive and submit RFPs.
2. The Accounting department had a system to pay payroll taxes via B2B file exchange
3. The supply chain management team had a system to send XML and flat files for product orders
4. Then there was the "official" EDI system that my IT team managed

I was quite frustrated to learn that different business units would have the nerve to implement EDI/B2B without my blessing. Later I learned the world revolved around the sun, not me. I was young and inexperienced. Different business units have their own reasons for not using the EDI department. I have heard the following:

1. The EDI team has an 18 month backlog - I need EDI today
2. There are not enough IT resources to deliver my project
3. The EDI department has time, but there are no available software developers to integrate the files into SAP
4. IT projects have a lengthy review and priority process to complete before anything can be done - I can't wait
5. I did not know it was EDI - it's just an RFP software application
6. The EDI team said my project was not a priority
7. No one in the EDI department would answer my emails
8. I can outsource the EDI cheaper and faster than implementing it internally

Whatever the reasons, business units will find a way to achieve their objectives. If the EDI/B2B team can not quickly and satisfactorily respond to a need, then other means will be found.

I am working on a number of projects now that involve SAP and the Accounts Payable department using a managed EDI/B2B service to send Purchase Orders and receive supplier invoices without the EDI/B2B department getting involved. Sometimes the EDI department does not even know about it. For some of the reasons listed above, the AP department chose to get things automated on their own without using internal EDI resources.

I have also seen a recent trend where large companies are outsourcing their AP processes. They contract with a company that specializes in AP optimization. These services often include the following:

• scanning of all incoming paper invoices
• manually reviewing and correcting the digitized document
• Add the digitized invoice to an approval workflow with integration into SAP or other ERP
• Convert as many paper invoices to electronic invoices as possible to reduce processing costs. Electronic invoices generally involve a conversion from paper to EDI/B2B.

It is easy to understand why the AP department's choice of using a managed services provider for optimizing their AP processes and reducing costs, often includes a managed EDI services component. Electronic invoices are simply cheaper and faster to process. The managed services provider can reduce costs and increase profits using EDI/B2B.

Now here is an interesting point to ponder - Why wasn't this already done by the company if the results are a reduction in costs and faster invoice processing? Why does it take an outside managed services company to introduce EDI/B2B into the vendor invoice process?

I predict that outsourcing EDI/B2B services will become increasingly popular as IT departments and EDI departments are downsized or outsourced. SAP is also developing a number of Netweaver PI based strategies that will make EDI easier to implement and/or to outsource to EDI managed services companies. EDI is being developed into an on-demand service that is a part of SAP's Enterprise Services Repository strategy. The data required for many business processes will already be identified and made available for use by either internal EDI departments or increasingly by EDI managed services companies. Going forward, if the internal EDI department is unable to quickly and efficiently support a new project, there will be an SAP designed method for implementing EDI directly from Netweaver through an SAP certified managed EDI services provider. EDI managed service providers will be able to connect Netweaver-to-Netweaver and quickly and cost effectively ramp-up and support your EDI requirements without adding headcount or additional EDI software licenses.

Prior to SAP's active involvement in the EDI solutions arena, they would define IDocs, which are published APIs that can be used by third party EDI software vendors to import and export business data. This was nearly a hands-off approach by SAP. It appears now that SAP believes there is a significant benefit to their active involvement in defining simpler and more efficient means of implementing EDI/B2B.

SAP's slogan of "Business Beyond Boundaries" seems to identify a new emphasis on helping their customers to more effectively and efficiently communicate business data with their business networks. An SAP system is dependent on receiving accurate and timely data from supply chains, logistics providers, vendors and customers. If existing EDI/B2B systems, implementation strategies and methodologies are in fact an obstacle to a successful SAP implementation, then you can understand their motivations for getting involved now.

I look forward to learning more about SAP's aggressive 2009 EDI/B2B strategy at Sapphire this year.

****************************************
Kevin Benedict,
www.b2b360.com
http://www.linkedin.com/in/kevinbenedict

The Real Purpose of EDI

It is easy when you are focused on implementing an IT project to forget the real purpose of your efforts. EDI / B2B departments are no different. EDI/B2B communications are simply enablers for business processes - like SAP's Supplier Collaboration Network. They enable the business processes to be extended out to your supplier network. The implementation of the business process, in production, is the key to success, not the EDI capability.

Wikipedia defines supply chain management as follows: Supply chain management (SCM) is the management of a network of interconnected businesses involved in the ultimate provisioning of products and services required by end customer. The emphasis is on "management of a network." The word "interconnected" refers to the ability to "communicate" between members of the supply chain (often via EDI/B2B messages). This is useful in the context of enabling the management of the network.

The ability to "interconnect" or "communicate" does not in-and-of-itself produce the products and services that the end customer desires and is willing to purchase. A manufacturer does not make money by sending EDI messages. They make money selling and delivering products and services. If they could manufacturer and sell products better and cheaper without EDI they would. EDI is simply a neccessary cost of goods to facilitate communications.

How much profit does a manufacturer receive by sending EDI messages in 6 different industry standard formats and 36 different customized configurations? The answer - NONE. The strategic value comes from the ability to communicate business data, accurately and quickly so it can be acted upon, not from the ability to support all of these costly file formats, standards and custom configurations. It is the business data, not the EDI message that is critical.

If there were an easier and less expensive method of communicating business information between companies in the supply chain network, then CFOs and CIOs would be eager to utilize it. SAP is working on this strategy now. EDI does not go away, but it can become an on-demand service in the Enterprise Services Repository tied into various pre-defined SAP business processes. These strategies are being implemented in production environments now.

****************************************
Kevin Benedict,
www.b2b360.com
http://www.linkedin.com/in/kevinbenedict

Consolidating EDI and B2B Systems to Reduce Costs

It is common for large companies to have multiple EDI and B2B systems in place in different geographical regions, divisions, subsidiaries and in newly acquired companies. It is also common for large companies to try to standardize key processes across these locations to reduce costs. For many of the same reasons that companies seek to update different instances of SAP onto one instance, companies are seeking to do the same with their disparate EDI systems.

Think about this - one company I was working with recently has doubled in size since 2006 as a result of many acquisitions. Nearly all of these acquisitions came with their own EDI department and EDI system. Each of these systems would have a cost that includes resources like the following:

• 1 EDI Manager (full-time)
• 5 EDI specialists (full-time)
• 1 Database Administrator (part-time)
• 1 IT standards team (part-time)
• 2 IT software engineers working on integration projects (part-time)
• 3 SAP solutions specialist defining business process and data integration requirements (part-time)
• 1 Communication/Security specialists (part-time)
• 1 IT Business Analyst (full-time)
• 1 IT Systems Analysts (part-time)
• 6 Business Process Specialists (part-time owners of business processes and different database applications)
• 1 IT Help Desk person (part-time)
• 3 IT Managers (part-time)
• 1 IT Network Administrator (part-time)
• 1 IT Data Center/Server Manager (part-time)
• 1 IT Web Portal Specialists (part-time)
• 2 IT Project Managers (part-time)
• 3 Directors of Business Units (part-time)

The above list reflects typical IT resources involved in a mid-sized company's EDI initiatives and represents some serious costs (assume $1 million annually). Let's now multiply the above resource costs by 8 different divisions and subsidiaries(total $8 million annually). Next add the amount of annual maintenance/support/upgrades/training for 8 different EDI translator systems (assume $2 million combined costs annually). Yikes! The total could easily top $10 million per year to support 8 different EDI environments and initiatives. You can see why aggregating these onto one shared EDI/B2B solution or service on one instance of SAP across all divisions and subsidiaries would be desirable.

That is a nice concept, but all of the EDI messages, EDI translator maps and application integration maps are specific to the various IT environments and database applications in use. It would be very difficult to ask your internal IT department to switch all of these processes over-night. There needs to be a migration strategy. If your strategy is to standardize processes on SAP and if possible on one instance of SAP, then you may want to also look at standardizing your EDI/B2B systems on one EDI solution or service that is aligned with SAP so it all happens at the same time and in the same project.

SAP is developing, both internally and through partners, Enterprise Services Repositories strategies for EDI/B2B that are designed to make these issues much simpler and less expensive for all. It may be worth understanding SAP's strategy before embarking on this journey.

If you would like to discuss this topic in more detail please contact me.

EDI and B2B, Procure-to-Pay and AP Optimization Strategies in a Troubled Economy

There is a lot of interest these days in AP optimization. Why? Companies are looking under every desk and business process for inefficiencies and cost reductions. AP optimization is a good place to look. Many companies that I have spoken with over the past few weeks are very interested in reducing paper processing and data entry costs associated with handling and managing inbound paper invoices. In addition to cost reduction, CFOs are also seeking ways to speed up the processing of inbound invoices so they can take advantage of early payment discounts with their key vendors.

It is worth noting that many companies cannot take advantage of early payment discounts because the process of managing the paper invoices takes too much time. Paper does not easily give up it's information. Somehow the information on the paper invoice must be extracted and entered into the AP software application, approved or rejected and payments made. Sometimes this takes 45 days just to process.

I have worked on a number of projects over the past few weeks where CFOs were seeking to out-source the entire process of handling inbound paper vendor invoices. They want the following:

1. Reduce the current costs of processing the paper (labor, IT, facilities, etc.)
2. Scan/OCR the data on the inbound paper vendor invoices to quickly digitize it
3. Have a human review the scanned data and fill-in any missing or unreadable data from the original paper copy
4. Submit the digitized invoice into a work flow for approval or rejection
5. Convert as many paper invoices to electronic EDI or B2B file transfers as possible to achieve real-time integration with SAP

I was surprised to learn this year how many CFOs were interested in out-sourcing this entire process. It seems there is little perceived value of keeping the following functions in-house:

• paper processing
• scanning/OCR
• data review and correction
• converting paper invoices to electronic invoices (expanding the use of EDI and B2B data exchanges)

The CFO's office wants the benefit of all-of-the-above, but not necessarily the internal costs of doing it. There are a number of companies now that have developed a managed services offering that combines state-of-the-art scanning technologies, low-cost labor, AP work flow, best practices and managed EDI/B2B services for AP optimization. I have read several analysts reports recently that suggest this is a rapidly growing trend. Typically the costs for these managed services are considerbly less than processing in-house.

Once the AP process is optimized, the CFO will have the flexibility to capture negotiated early payment discounts, and to start looking at things like dynamic discounting. Dynamic discounting is when the CFO or his/her team can negotiate in real-time with key large suppliers to pay earlier than agreed in exchange for additional discounts. On large invoices these numbers can be meaningful.

Kevin Benedict, http://www.crossgate.com/

The Process of Implementing EDI and B2B

EDI and B2B messages can not be implemented with a trading partner without knowing what data is going to be sent or received. If a trading partner sends you an EDI data file, it looks like a strange, cryptic message. You may see many different codes, numbers, separators and words. You have no idea what they mean. So how do you make something useful with it? Your trading partners must send you an "EDI Implementation Guide."

An EDI Implementation Guide is a document that explains what is in the EDI data file. OK, now you have the secret decoder document. It identifies what each code and data element in the Implementation Guide means. It tells you the EDI standard, version and EDI transaction (e.g. 810 Inbound Vendor Invoice) that is being used. It tells you what subset of the 810 Inbound Vendor Invoice your trading partner uses. This is important since an 810 Inbound Vendor Invoice may have 300 possible data elements, of which you only need 62 for your SAP IDoc (just an example).

The EDI Implementation Guide is used to help you configure your EDI translator so it understands what to expect when it receives a message. Using the example above, you configure your EDI translator to expect the same file as is defined in the Implementation Guide. The configuration of your EDI translator is a slow manual process. Any typos or data entry errors makes the configuration invalid. Once the EDI translator is configured you can import a test file with valid and compliant data to test your configuration.

It sounds simple when I wrote you could import a test file, but trading partners hate making test files on new messages. It is just boring work. Someone has to read the new EDI Implementation Guideline and maually create a test file that exactly matches the implementation guide. If you create an invalid test file, the testing process gets all messed up.

Now, you as the recipient of the EDI message must ensure that the Implementation Guide, your trading partner sent you, contains the necessary data that your IDoc requires. If it doesn't, you need to contact your trading partner and negotiate with them to edit their implementation guide, EDI message and data file to include the data you need. This is not always easy, since your trading partner may not want to bother. This is where the Dale Carnegie class you took 20 years ago pays off.

Here is where EDI implementations are just plain old fashion and silly. You ask the SAP support team to send you the IDoc documentation that identifies the data needed. You ask your trading partner for their EDI Implementation Guideline, then you make some popcorn, put on your reading glasses and start comparing them line by line. Doesn't it seem like this could be done in a more automated fashion? Once you have completed the analysis, you must now understand what the IDoc means by Address Line 2, and compare it to the meaning of Address Line 2 in your EDI Implementation Guide. Perhaps your trading partner uses that element name to mean Suite #, but your IDoc uses it for the Building name (again just examples) but the point is you must also understand the semantics of each data element. Keep in mind, that your trading partner had to go through this same process at their end of the transaction.

Let's consider the above scenario, and expand it to 3,400 trading partners using 55 different EDI messages in a wide range of different EDI standards, versions, message types, subset lists, languages, and custom configurations. Does this sound like fun? Is there any wonder that companies rarely can implement EDI with more than 10-20% of their trading partners? The process of automating and extending your business processes to your external business network is inhibited by the fact that implementing EDI/B2B is a slow, paper-based, hard and costly MANUAL process.

There are methodologies, tools and strategies that can be implemented to make EDI/B2B implementations easier, but they are usually only available to very large companies with giant EDI departments and budgets, or EDI/B2B managed services companies that can benefit from the economies of scale required to invest in them.

Let's review the process:

• Your trading partner must understand the data needs of their ERP
• Your trading partner converts the needs of their ERP into the appropriate EDI message
• Your trading partner writes an EDI Implementation Guide
• The implementation guide must be written accurately
• The meaning of the implementation guide must be understood
• The information in the implementation guide must be used to accurately configure the EDI translator
• Test data files that exactly match the implementation guide must be created
• The IDoc requirements and definitions must be configured in the EDI translator accurately

What are the odds that all of these steps can be done accurately the first 6 or 7 times?

Kevin Benedict, www.crossgate.com

EDI Message Implementation Information for SAP Users

The following information is needed to implement a new EDI message in an SAP environment if you are implementing internally using your own EDI translator system and team. It is a lot of information for one message, but it is necessary in order to understand exactly what data needs to be consumed or produced by your applications and business processes.

Every electronic message will require this information. If you have 1,000 trading partners each sending an electronic invoice, then you would need 1,000 implementation documents containing the information listed below. Why 1,000 documents, because each will be tested separately and often will contain small differences in the data sent in the files, plus the trading partner contact information will be different each time.

Required EDI/B2B Message Information:

• Project Scope - Who is this EDI/B2B message for and when does it need to be in production?
• Data exchange testing schedule
• Data exchange production schedule
• Your Trading Partner's contact information
• EDI Manager, Phone, Email
• EDI Technical Lead, Phone, Email
• Business Unit Project Owner, Phone, Email
• EDI Transaction Set / Name Information
• Inbound or Outbound
• EDI Standard and Version
• EDI Implementation Guide
• EDI test data file to match the Implementation Guide
• Communications/Transmission Information
• VAN Name
• VAN Phone, Email
• VAN account information
• Duns ID
• ISA ID
• GS ID
• Transactions schedule - batch, scheduled or real-time
• Production Qualifiers
• Test Qualifiers
• FTP Site information, user names, passwords
• IP Address (Production) -User ID, Password, Directory
• Timing of transaction
• IP Address (Test) -User ID, Password, Directory
• Frame Relay Subscription Information
• SAP IDoc used
• Is the IDoc standard or custom
• SAP Database Administrator, Name, Phone, Email
• Is there a separate Application Interface for different non-SAP solutions in the system
• Application Interface Location
• Application Interface Contact and Contact Manager - Name, Phone, Email
• Application data file location
• Inbound application data mapping specification
• Application Data format (delimited, fixed length?)
• Outbound application data mapping specification
• Application test data source
• Application Implementation Guideline
• Transaction Set/Name
• Inbound/Outbound
• Standard/Version
• Implementation Guide Location and owner
• XML Schema/DTD Location and owner
• Acknowledgments required y/n
• Are 997 functional acknowledgments required?
  

If you would like to discuss this topic in more detail please contact me.

SAP Outside the Four Walls - EDI, B2B, Supply Chains and Business Network Transformation

SAP has spent many years developing business software applications and standardized business processes for use within the four walls of an SAP shop. At Sapphire this year, SAP CEO Léo Apotheker spoke about businesses without boundaries. The context being that enterprises must understand the importance of connecting and communicating business information electronically with their external business networks. Today, companies require seamless business processes both inside and outside the four walls of their business.

In today's world of multi-enterprise supply chains, 3PL (third party logistics providers) and discrete manufacturing environments companies can no longer be satisfied with business processes that stop inside the four walls. These business processes are extended outside the four walls through various EDI and B2B messages that can be sent in real-time to their relevant business network partners. The visibility provided by real-time data exchanges ensures that management can make decisions based upon accurate and timely information and analytics.

Often the ability to communicate and extend business processes to your business network partners is inhibited by old and out-dated EDI/B2B strategies. EDI and B2B data exchanges are even more important today than ever before. New and different strategies must be adopted to ensure that quick and cost effective methodologies are implemented that enable large numbers of new business network partners to be quickly added or changed as markets and products change. Traditional, costly, multi-year on-boarding EDI projects never worked well and are not the answer today.

SAP users need to understand how SAP Netweaver PI, Global Data Types and the Enterprise Service Repository strategies will impact the traditional EDI environments and processes going forward. A number of recent press releases and interviews with SAP executives have revealed that the term business network transformation has significance behind it. SAP is aggressively developing solutions both internally and through partnerships and investments to transform the way EDI has traditionally been managed and implemented.

It takes a company with the size and influence of SAP to be able to make the radical changes in the EDI/B2B industry that have long been recognized as needed by veterans of traditional EDI campaigns. It will be an interesting ride and will make IT departments reconsider their investments in traditional EDI systems.

If you would like to discuss this topic in more detail please contact me.

Supply Chains, EDI, B2B, Small Worlds & Six Degrees of Kevin Bacon

The game "Six Degrees of Kevin Bacon," in which actors can be connected to one another through their appearances in films with actor Kevin Bacon, works because Hollywood movies are a "small world," in mathematical terms. It's a world where actors are grouped into clusters (the casts of each film), and there are many interconnections between the clusters.

Two Cornell University mathematicians have now shown that small worlds are probably common in many networks found in nature and are easy to create in systems as diverse as networks of people, power grids and the neurons in the human brain. All it takes is a few extra random connections. ~June 4, 1998, Bill Steele, Cornell University

The keys to the game "Six Degrees of Kevin Bacon" are the connections between Kevin Bacon and other actors/actresses through the films they worked on together. This is how it works - actors are connected by 1 degree if they have worked on a film with Kevin Bacon. If an actress knows an actor that worked with Kevin Bacon, the actress has 2 degrees of separation from Kevin Bacon. This is the same as the website Linkedin showing that you are linked to the VP of Marketing at Cisco because your neighbor knows her. With each degree of separation the numbers of people in your network increases exponentially.

In the context of Business Networks, companies are connected to each other through business relations that are often transacted by EDI or B2B data exchanges. Company A may send EDI messages to company B, and in turn company B sends EDI messages to company C...

It is interesting to think about the concept of Small Worlds and Six Degrees of Kevin Bacon as it relates to Business Networks using electronic data exchanges (EDI/B2B).

• Company A electronically connects with company B via an EDI/B2B managed services hub, and sends electronic purchase orders to, and receives electronic invoices from, company B.
• These electronic data exchanges(purchase orders and invoices) are first configured and then added to the repository in the EDI/B2B managed service hub they both share.
• Eight additional companies join the EDI/Managed services hub and then query the Hub's repository and find they can make use of those pre-configured electronic purchase orders and invoices to also communicate with companies A & B.
• The eleventh company that joins the hub can connect to these electronic data exchanges with all 10 companies that are using them (assuming they conduct business with them).
• Company A can see that company B is also exchanging electronic ASNs (advanced shipping notices) with 34 other trading partners - 28 of those trading partners also do business with company A.
• Company A requests connections via the hub to the 28 using the pre-defined ASN messages. Connecting once to the ASN enables company A to support and exchange another 28 electronic messages with trading partners with very little effort.
• Each of those 28 companies can now view and understand how they can connect with other companies that utilize the hub. This is what is called the Network Effect! Every new connection adds value to all business network participants.
• If 1,ooo companies on the hub each activated one new and unique trading partner per month you would have 12,000 additional companies on the network each year with pre-configured and pre-defined EDI/B2B messages. Working on your own would provide you with only 12 new trading partners per year rather than 12,000. The second year, with no growth you would have over 24,000 companies on the business network rather than just 24 that you could add on your own.
• The value of connecting to a rapidly growing EDI/B2B managed services hub grows exponentially each year that it operates. Again, let's consider the value of Linkedin. The value of Linkedin increases substantially with each new contact and their network that is added. It works the same way with an EDI/B2B managed service hub.

"It's not just the world of people that's small," says Steven H. Strogatz, professor of theoretical and applied mechanics. "There's a unifying mechanism in nature that makes things small." The useful part is that adding just a few connections to something like a cellular phone system or perhaps even the Internet (or EDI/B2B Business Network) might greatly speed up communication. (June 4, 1998, Bill Steele, Cornell University)
The game of Six Degrees of Kevin Bacon works because the links between clusters (i.e. films and actors/actresses) are collected, stored and queried in a database that is accessible. The same is true with Linkedin. The value of Linkedin is the gathered, stored and searchable database of links between people that is accessible by others. The world of EDI/B2B is being transformed with these same aggregation strategies. Gather the names of the companies, their links (supported EDI/B2B messages), integration maps and make this information accessible for reuse by the entire business network.
So far in this article we have just focused on the value of the network effect as it relates to connecting with other companies quicker and easier using pre-existing connections that are listed in a data repository. There is an even more powerful network effect if the participants share the same back-end software application, such as SAP, and use the same set of pre-defined business processes. Why, because if the back-end application and the data that is produced and consumed by this application's business processes are known in advance, then they can be pre-built once and used millions of times in the business network. The efforts invested in the first implementation can be reused by the entire business network that share the same back-end software application and business processes.
If the EDI/B2B managed service hub added and stored information on SAP and its business processes that are connected to the EDI/B2B managed services hub, you could quickly connect your SAP business processes to all other trading partners that produce or consume those SAP centric electronic exchanges. In addition, if the EDI/B2B managed services hub was also built on SAP Netweaver technology, then the back-end integration would become even simpler and Netweaver would become, in effect, your gateway to the EDI/B2B hub and the entire business network. Suddenly, there becomes the very real opportunity to quickly and cost effectively communicate EDI/B2B messages with potentially tens of thousands of connected companies in a business network.
It is important to recognize what makes a network effect possible. The network effect is not available if a company chooses only to use point-to-point EDI/B2B communications from your private internal EDI/B2B system. The network effect requires the aggregation of company and EDI/B2B message information across a community or business network. The network effect is the result of reusing and exploiting all the connections and integrations that other business network participants contribute to the managed services hub. There must be a centralized data repository that enables companies to recognize and realize reusability of EDI/B2B connections and SAP (or other ERP) integration maps.
The Six Degrees of Kevin Bacon game demonstrates how easy it is to be connected to people around the world. In the game, it has been found that nearly everyone on the planet is connected to everyone else within 6 degrees of separation. In the world of business the degrees of separation are even less. Taking advantage of this phenomena in the world of business requires connecting to other companies that share a common business network and an EDI/B2B hub. Exploiting this phenomena is called Business Network Transformation.

The question for business managers and IT managers today is this - are you taking advantage of business networks, the network effect and the phenomena of the Six Degrees of Kevin Bacon? If not, you are significantly limiting your EDI/B2B value and potential. Most companies that limit their EDI and B2B communications only to the connections that their internal EDI team can fit into their busy schedules rarely implement with more than 10-20% of their trading partners. Implementing with only 10-20% of your trading partners severly limits the potential ROI, real-time visibility to data and costs savings available to companies that automate their external business processes.

If you would like to discuss this topic in more detail please contact me.

EDI & B2B Relationship Management for SAP Users

Business Network Collaboration between companies is more than just the exchange of business data and electronic documents between business partners. It's about a complex set of collaborations and communications between the various parties and the coordination of these activities. It's about supporting these sophisticated relationships virtually and seamlessly all around the world so that business continues to move at the speed of the Internet. It's about business network collaboration. Business Network Collaboration needs to be documented.

The following list identifies a few of the categories of information that needs to be documented in order for a company to effectively and efficiently conduct EDI & B2B with trading partners.

1. Document internally preferred industry EDI/XML/B2B standards, EDI implementation guides, IDocs, XML schemas and web service interfaces, and organize by business process and trading partner.
2. Document the details of the business process that is being automated through the use of EDI or other B2B formats.
3. Document the timeframe requirements and priorities of implementing various business partners. Who is most important and needs to be implemented first?
4. Document your EDI/B2B vendor/service provider's sales contact and account information.
5. Document any EDI/B2B consultant’s or internal software engineers involved in specific implementations. Know how you can contact them?
6. Document your trading partner’s EDI transaction set(s), B2B messages and XML schemas in a standardized guideline. Include all of the semantic and syntax information.
7. Document and store your trading partner’s business documents including trading partner agreements, project schedules, security requirements, relevant business agreements, NDAs, etc.
8. Document the names and contact information of all the people in your trading partner's organization that are involved in the EDI/B2B implementation (who manages the business process, EDI translator, security, communications, helpdesk, legal agreements, IT priorities, etc).
9. Document task lists (specific to a trading partner’s implementation plan and schedule)
10. Document your internal issue resolution and escalation processes.
11. Document your EDI/B2B vendor's helpdesk information, support plan information, renewal dates and history.
12. Document the hardware, software and networks involved in your internal EDI/B2B processes so you can quickly resolve issues and answer questions from your business contacts and IT managers.

Here is the challenge. Where do you document and store all of this information? EDI software vendors don't care. They do not feel this is their responsibility, although it is an absolute requirement for the EDI/B2B support and implementation team. I would suggest that the first step of any EDI/B2B implementation project is to design a database application that can be used as the designated repository of all the information listed above. This is how managed EDI/B2B service providers like Crossgate must do it in order to manage tens of thousands of implementations effectively.

If you would like to discuss this topic in more detail please contact me.

The Impact SAP Upgrades Have on EDI and B2B Operations

Upgrades to SAP have the potential to break all or most of your current point-to-point EDI maps. If you have not already determined the impact, you may want to do it ASAP. No one likes surprises, unexpected project delays, costs and embarrassment.

Why would an SAP upgrade break your point-to-point EDI and B2B maps and communications with your trading partners? SAP upgrades often include new functions and features that both produce and consume new kinds of business data. The data in your IDocs and EDI messages may also need to be edited to accommodate these changes. In addition, the order and the location of data in your EDI/B2B files might change and the location of the data in your software application might have changed. Any of these changes will require changes to your EDI/B2B processes and maps.

There are 2 important terms EDI/B2B gurus often use when describing an EDI/B2B message:

1. Syntax
2. Semantics

Here are their definitions:
Syntax is used to refer directly to the rules and principles that govern the structure of a sentence or file (or the structure of an EDI message)
Semantics is the study of meaning in communication (in EDI - does the address mean Bill to, or Ship to?)

If there are any changes to the IDoc, EDI message, SAP application, business process, syntax or the semantics of the IDoc or EDI message data, then you will have changes to make to your EDI/B2B files and processes in addition to the upgrade of SAP. These changes may impact not only the EDI-to-SAP, SAP-to-EDI integration maps, but also the EDI-to-Trading Partner and Trading Partner-to-EDI messages. Let discuss a scenario:

1. Let's say you have 1,000 EDI/B2B trading partners exchanging at least 4 different EDI messages each (total 4,000 EDI/B2B messages). Some percentage will ask you to exchange a customized EDI message with them. This means they want unique data to be exchanged between your 2 companies that is different from other trading partners. This often means you must not only create, document and implement a new and unique EDI message for them, but you must also customize an IDoc just for them.
2. Let' say you have 500 custom EDI messages out of the 4,000 that are in production.
3. In this scenario you will be using a minimum of 504 unique EDI messages and 504 unique IDocs. That is 1008 mappings....a represents a significant effort in time and costs.
4. You spend several years customizing, testing and implementing all of these EDI messages and their associated IDocs, and then the business announces they are going to upgrade SAP to take advantage of new features, functionality and technologies.
5. You immediately research and analyze the impact the new upgrade to SAP will have on your IDocs and custom EDI messages and realize you will need to redo most of them....YIKES!
6. Someone needs to add this additional project to the SAP Upgrade project plan and budget.

There are ways to make upgrades to SAP less painful to both the business unit and the EDI/B2B department. It takes some foresight and planning, but there is an IT strategy that uses a "canonical data model" approach. The definition of a canonical data model is - a design pattern used to communicate between different data formats. Crossgate, a managed EDI/B2B service provider uses this strategy for SAP users. The use of an intermediary canonical data model in an EDI/B2B/IDoc scenario is as follows:

• All EDI/B2B messages are mapped to the canonical data model, NOT directly into IDocs or other SAP formats as you would in a point-to-point mapping scenerio.
• All IDocs are mapped into the canonical data model, NOT directly into EDI/B2B messages like you would in a point-to-point mapping scenario.

This may seem like extra work and an extra IT systems layer, which it is, but it reduces the work involved when changes are required to your SAP system in the future. Let me explain:

• You can set-up one Purchase Order IDoc between SAP and the Purchase Order in the canonical data model, which in turn can accommodate all of the customization required by suppliers, rather than going through all the effort of supporting hundreds of different IDocs
• Hundreds of customized Purchase Orders sent in via EDI messages can all interface with the one giant Purchase Order in the canonical data model as well.

In the above scenario - in the future when upgrades to SAP are required, only the one Purchase Order IDoc connected to the "canonical data model" needs updated, not hundreds of IDocs that a traditional point-to-point mapping environment would require.
In summary, upgrades to SAP can break many point-to-point IDoc to EDI processes. Companies must expect significant upgrades about every 5-7 years, so why not create an IT architecture that can make these upgrades much simpler and less painful? This is the strategy used by most EAI (enterprise application integration) solutions and large EDI/B2B managed services companies that must utilize these strategies to achieve economies of scale and reusability of processes.

If you would like to discuss these topics in more detail please contact me.