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.

Staffing Resources Required to Implement EDI

When budgeting time, resources and personnel for setting up, implementing, operating and supporting an EDI and B2B department, it is important to understand the complete picture. There are a large number of different business, database, development, support and EDI resources that will be needed. Earlier in my career, I served as an EDI Manager in a medium sized PC manufacturing company and here are the IT resources that I was using on a regular basis.

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 Oracle IT 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)

It may come as a surprise to many that contributions from 32 or more people are required to set-up and implement EDI in a medium sized company. Most are part-time, but their skills and experience are required in many planning and strategy meetings and on implementation projects.

The costs were easily over $1 million dollars per year in resources. That does not include the EDI/B2B system, annual support and maintenance, training and hardware costs.

Operating an internal EDI system cannot be an after thought. It requires a significant budgetary commitment from both the business units and the IT department.

I was managing an EDI team that needed to support many disparate software applications that required different business and systems experts, managers, developers and integration skills. That was certainly not the best and most cost effective IT environment to support. You could avoid many of the IT costs I incurred by standardizing on SAP and utilizing SAP’s Netweaver PI platform as your EDI/B2B integration point.
Companies that have standardized on SAP and utilize SAP’s Netweaver PI, have documented methodologies and business processes, a defined integration strategy for all of the various business processes and can decide between the options of either operating an EDI/B2B department internally, or using an EDI/B2B managed service provider.

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

EDI, B2B and Business Network Transformation Needs a Revolution Not an Evolution

Business Network Transformation, as I understand it, means changing the way companies have traditionally exchanged electronic business data with their trading partner communities. Efforts to transform traditional EDI have been underway for many years, but I think we need a revolution, not an evolution. Why -Because the approach to B2B/EDI is out-dated and inefficient. Let's discuss some of the issues:

1. Most companies only exchange electronic business data with about 10-15% of their trading partner community because it is too resource intensive and expensive to proceed further. The ROI takes too long to achieve and the effort is too great. Companies give-up trying to connect more companies and simply fall back into a support mode and never achieve the complete ROI. The ROI is only maximized when you replace all paper processes with electronic data exchanges between trading partners. There will be a point of diminishing return on your on-boarding efforts, but many more trading partners could be transformed from paper to EDI/B2B if the cost of on-boarding were much less.
2. The ongoing improvement and development of new and more complete EDI/B2B standards is always welcome, but does nothing to resolve point number 1.
3. Great inefficiencies are built into the traditional approach to EDI/B2B, and to continue to build and grow your trading partner communities simply multiplies these inefficiencies. In the early 20th century, manufacturing companies needed to purchase their own electrical power generation systems to provide power to their own factories. They purchased giant generators, hired staff, installed fuel tanks and developed their own electrical infrastructures. This was necessary only up to the point when the electrical service was available to everyone through the power grid of the local electrical utility where shared costs and economies of scale reduced the overall costs. Once there was electricity available on power lines in front of the factory, companies could reduce their expenses and efforts by connecting to the managed utility service. EDI/B2B must adopt a similar approach.

Example of Inefficiencies:

• 100 companies all need to exchange EDI with each other and their trading partner community (business network). 100 companies all purchase expensive EDI systems for $250,000 each (total $25 million).
• Each company then needs to integrate the EDI data into their ERP. Let's estimate the integration projects at $250,000 each for 100 companies (total $25 million).
• Each company hires 5 EDI specialists and an EDI Manager for an annual total of $600,000 (total $60 million annually).
• Each company then needs to purchase hardware for the EDI system - 1 production server, 1 fail-over server and 1 test server for an estimated total of $30,000 (total $3 million).
• The total costs in this example to get EDI up and running for 100 companies the first year is $113 million.
• The $113 million is for year 1 only. If you factored all the staff costs, EDI system upgrades and annual maintenance/support costs, server costs and integration costs over 3-5 years it will be much higher.

The inherent inefficiencies in EDI/B2B today have given rise to a whole industries that thrive on EDI/B2B chaos. The more difficult to implement - the more services revenue the EDI vendors get. This is perhaps tolerable when everyone is making large profits, but in a tight market all companies are seeking efficiencies and I question if the traditional approach to EDI will survive the, dare I say - inevitable revolution in B2B?
The $113 million total is the total amount if each company purchased and implemented EDI/B2B separately (as most do today). Isn't it possible for ED/B2B to follow the example of the electrical utility industry? Can't companies view EDI/B2B as an important and necessary utility and work together to achieve economies of scale and reduce their development, implementation and support costs? Can't the business community simply organize a managed B2B/EDI service and utilize it for a monthly fee based upon use or the size of their trading partner community, rather than make large individual investments that only address the needs of a handful of their trading partner community and make achieving a positive ROI very difficult?

EDI/B2B is never simple, but there are ways it can be made much easier and more cost effective. These methods mostly involve combining information in a common repositories and centralize systems and services so each company can benefit from the combined work of the entire trading partner community and achieve the network effect. Let's look at another admittedly over-simplified but useful example of efficiencies that are available if the EDI/B2B community were to organize their efforts:

1. The 100 companies decide to support one EDI/B2B managed services business which purchases and manages an EDI/B2B system that can provide EDI/B2B services for all (saves $24.75 million).
2. This EDI/B2B managed services business develops pre-built integrations for the major ERPs and their associated core business processes. These can then be used by all 100 companies, rather than everyone incurring the expense of individual integration projects, tools and support (let's say it costs $5 million to develop the integration maps for the community, so the community saves $20 million).
3. The EDI/B2B managed services business provides 24x7x365 support and staffing and on-boarding services (reduces the expenses in each companies' IT department for a total of $50 million annually - reduce EDI staff from 6 to 1 EDI Manager)
4. The EDI community does not have to purchase and support 3 servers each (saves $3 million)
5. The EDI/B2B managed services business could be funded by small fixed priced set-up fees and monthly maintenance and support fees based upon connected trading partners only. The costs for this service could be spread out over several years so it is easier and faster to achieve a positive ROI.

These 5 areas of savings could be significant as long as the set-up fees and support/maintenance fees were reasonable, and there are still more possible efficiencies that could be recognized. I recognize that there would be service fees, but they would likely be much less than self-funding an entire EDI operation internally.

1. Let's suggest that a central repository is created (with a canonical Data Model) which enables all 100 companies to map their business processes and data requirements into this centralized repository.
2. Each of the 100 companies in the EDI community connect to 100 additional trading partners through the EDI/B2B managed services business. Now there are 10,000 companies connected into this business network.
3. The 10,000 trading partners could also be mapped into a canonical data model so their maps could be reused by others in the network.
4. Now all 10,000 trading partners are available to exchange EDI/B2B business data to all of the original 100 companies in the EDI community and each other. NOW there could be opportunities for HUGE efficiencies. Each time a new trading partner is added - it is immediately available to all 10,100 of the companies in the business network.
5. At this point a registry of the 10,100 trading partners (100 original plus 10,000 trading partners) can be established that enable all 10,100 to search through the lists of connected companies and easily connect with more trading partners. They could replace more paper based processes with more electronic connections. This produces further efficiencies and reduces processing and administration costs even more.

There are of course challenges to this vision.

• How would you organize 100 companies to work together for the common good?
• How would you cost effectively map the business processes and integration points of the original 100 companies in the EDI community?
• How would you pre-build integration maps if you don't know all the database applications that you need to support?
• This has been attempted by several industry EDI HUBs in the past with limited success. How would you improve and make it work?

The key, I believe, is in finding commonalities in the first 100 companies in the EDI community. Focus on 100 companies that all use the same ERP like SAP. Most companies, using the same ERP, have similar data requirements for common business processes like invoices and purchase orders. Focus on supporting SAP users with a subset of EDI/B2B message types and business processes. Provide a significant ROI on these. Expand support for an increasing number of business processes and EDI messages until there is full coverage. By starting with a KNOWN ERP you can effectively manage integration projects and leverage your efforts across a broad user base and keep the upfront investment reasonable which keeps the prices down for the customers of this managed service.

In this scenario - SAP is what all the 100 companies have in common. This can be an aggregation point for creating cooperation. The ability to leverage SAP work across all 100 companies is understood and well documented. SAP's support would make this all the more interesting.

The term business network transformation - changing the way things are done today in EDI. How long will companies continue to try to self-fund the entire costs of implementing EDI/B2B the old fashion and inefficient way?

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

EDI & B2B Intelligence & Metadata

When many people think of EDI or B2B systems they most often think of the of the following:

• EDI translator software
• VANs or AS2
• File formats
• B2B or EDI standards
• Implementation Guide Editors and Testing suites
• Web Services
• Application Servers
• Customer or supplier web portals
• XML editors
• Communication Protocols

These are all part of most EDI and B2B systems and are useful tools, but the most value components of a EDI and B2B system are the B2B metadata repositories (B2B MRM), and an effective database application to manage your business network ecosystem. The concept of a B2B MRM may include a number of different technologies, methodologies and strategies among them: canonical data models, global data types, universal mapping databases, auto-mapping applications, B2B standards repositories, test data generators, testing tools, trading partner management solutions (CRM for B2B), API and integration script libraries, web services repositories, etc.

The B2B MRM concept is strategically important because it could alter the competitive landscape of the EDI/B2B marketplace and traditional ways of implementing EDI and B2B. Critical B2B information concerning database schemas, mapping specifications, process/work flows and trading partner profiles are developed and stored not in the EDI and B2B vendors’ applications, but rather in an independent database in a B2B MRM.

The projected result of the B2B MRM concept would be to commoditize EDI and B2B solutions (adapters, mappers, translators, communication gateways, etc.) and to uncouple the intellectual assets (maps, process flows, trading partner details) and to make them application/vendor independent. This concept has the potential to free up the customer from the EDI/B2B software vendor and to make EDI translators and VANs commodity items that could be changed at will.

Customers who fully utilize the B2B MRM concept would have both the freedom and flexibility to move between EDI/B2B vendors or On-Demand EDI/B2B managed service offerings. This has the potential of revolutionizing the EDI/B2B software industry and could enable a significant shift in power from the EDI/B2B application vendor to the end user.

Challenges to EDI, B2B, Business Network Transformation and Supply Chain Collaborations

Business Network Transformation is not easy today, and it is projected to become a much bigger challenge for companies. Recently the Aberdeen Group reported that IT departments are under increasing pressure to improve B2B collaboration as multi-enterprise supply chains are rapidly expanding.

Emerging multi-enterprise supply chains and extended customer networks make it critical for companies to have a strategy that is scalable and that enables the efficient automating of the communications and business processes between trading partners so there can be real-time collaboration. The answer is not to hire more staff, spend more time on the phones, and process larger numbers of paper documents. Business Network Transformation requires a different strategy and plan to quickly automate these data exchanges using emerging B2B/EDI/XML strategies, methodologies and technologies that are flexible, efficient and cost effective.

Let's identify some of the common challenges businesses face with their EDI/B2B efforts today:

1. Typically only 10-20% of trading partners are connected to the business network via EDI/B2B, causing slow, error prone and expensive paper based systems to continue to be maintained. This delays actionable information from reaching decision makers, reduces visibility and limits real-time collaboration between supply chains, customers, LSPs, etc .
2. 80% of the typical EDI/B2B department’s time is dedicated to maintaining existing B2B connections and EDI systems, this limits the opportunity to automate new business processes, on-board new trading partners and integrate more B2B messages. Without these the business units are not able to achieve their automation and collaboration targets.
3. I have seen many cases where the "tail is wagging the dog". The limitations of the company's EDI/B2B capabilities dictates what the business can accomplish. This is not a desirable or sustainable condition as it can impact the ability to deliver efficiencies, reduce costs, implement new and improved business processes, provide better customer support and the ability to realize profits.
4. Point-to-Point mapping of custom EDI/B2B messages create difficult, expensive and time consuming integration projects. The larger the number of trading partner’s in your network the higher your risk of a “combinatorial explosion” of mappings and integrations that are nearly impossible to document, maintain and efficiently support over time
5. Point-to-Point mappings and integrations break when changes are made to the data sources (Point A) and/or data destinations (Point B). Many companies support hundreds and even thousands of point-to-point integrations that can be broken by updating applications and databases. This IT integration problem alone has stopped or delayed many companies from updating and improving their software systems and IT infrastructures which prevents them from achieving the benefits of improved business systems and processes. Most companies upgrade or update their ERP systems every 5-7 years. This is a predictable problem that needs to be addressed at the highest levels.
6. EDI translator costs, server costs, VAN fees, annual maintenance fees, training fees, changing EDI/XML standards and specialized high-costs EDI staff result in significant yearly costs that often fail to generate the anticipated ROIs in the expected time frames
7. Backlogged EDI/B2B IT integration projects prevent the rapid on-boarding and integration of new acquisitions, business processes, customers and extended supply chain networks. This causes delays, poor customer support, lack of compliance and the implementation of costly, slow and error prone manual paper processes as a substitute for efficient processes
8. To take advantage of many emerging multi-enterprise supply chains, companies are required to collaborate with an increasingly large number of trading partners in near-real time. In order to participate, companies need to be able to quickly and cost effectively connect via EDI or other B2B data exchanges. The inability to quickly support these requirements may eliminate your ability to participate in these business opportunities and processes.
9. Sometimes the EDI/B2B department is unresponsive to the needs of the business units and this prevents the business unit from reaching their financial or performance targets. This is a common IT bottle neck and weak link in the business process chain that needs solved.
10. Many companies have a decentralized IT environment with multiple EDI/B2B systems and specialized supporting staff in different divisions, locations and business units causing duplication of expenses, integration projects, mapping, staffing and support that is unmanageable and unsustainable in the long term.
11. Limited or no reuse of mapping and integration work with point-to-point configurations result in costly projects that become increasingly problematic to support.
12. EDI/B2B implementation methodologies with limited or no reuse capabilities does not become more efficient over time. Efficiencies and scalability can only be realized when the ability to reuse the work is incorporated into the system, and standardized processes, maps and integration methodologies are utilized. The increasing demand for more customer and supplier B2B integrations means that this is a growing problem that needs resolved quickly - business network transformation.
13. Often a company’s high profile strategic plans for business network transformation and supply chain collaboration are delayed and/or not achieved because the IT department is unable to meet the requested time lines due to other priorities, existing IT development projects and limited IT budgets and resources
14. Many companies conduct business across multiple vertical industries that may require different EDI/B2B standards, content and data formats. Supporting a large number of different B2B standards and industry requirements may add substantial costs in training, specialized personnel and additional technologies.

These are a few of the common issues many companies face in managing their B2B/EDI efforts and capabilities. There is a consensus among IT analysts that the ability to connect rapidly and efficiently with greater numbers of customers and suppliers using B2B data exchanges is an absolute requirement. There is a growing sense of urgency to resolve many of these challenges.
SAP's 2008 emphasis on business beyond boundaries and focus on business networks, business network transformation and extended supply chain collaboration is timely and needed. I see the developments on Netweaver PI, Enterprise Services Repository, Global Data Types and recent efforts to help clients solve B2B challenges as good progress in the right direction.

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

Business Networks, Intellectual Assets & B2B and EDI

The assets of a company are not only found in their patents, products, brands, capital, customer databases, facilities, equipment, and inventories, but also in the intellectual assets they possess within their IT departments. These assets when managed appropriately can be a significant source of competitive advantage, especially when you depend on your business network to manufacture, market, sell and deliver your products.

Business processes and metadata (information about information) are a significant and important category of intellectual assets. They might include; processes for ordering supplies, processes for changing orders, processes for monitoring the delivery of orders, processes for generating and sending purchase orders and processes for accepting supplier invoices. Business processes are often executed by the purposeful movement of formatted data such as traditional EDI, XML schemas and other data formats in an organized, documented and repeatable manner. The big problem - rarely is this data easily found and available for efficient reuse across the enterprise. Often this exact process is being funded, designed, developed and deployed only once, in one location, with one product line in one division. This problem represents an enormous waste in most companies.

Business processes and their associated data requirements are often dispersed throughout the organization in different software applications, different spreadsheets, databases, technology platforms, physical locations and within the minds of different personnel. The lack of a centralized data repository to store and make searchable this information leads to the loss of thousands of hours of development time and accumulated intelligence, delayed projects and wasted money.

It is not just technical information that needs to be organized. The following list contains examples of other important information that must be gathered, documented, stored and organized specifically in the B2B/EDI arena:

1. What data does a particular business process require?
2. Where is this data located?
3. How is the data formatted?
4. What are the semantics of the data?
5. Are there existing scripts that have been written to import and export the data from the source?
6. Where are these scripts?
7. Are these scripts documented?
8. Who wrote these scripts and is this person available to debrief?
9. What are the mapping and transformation requirements for this data?
10. Does this data need to be transformed/converted into multiple formats?
11. Are there industry B2B / EDI standards involved?
12. Is there documentation concerning this particular business process?
13. Who are the business and technical owners of this business process both internal, and at your trading partner's location? How can they be contacted?
14. Are there documented security requirements?
15. Who are the business and technical owners of each step in the business process?
16. How can you contact them?
17. Who owns the applications and hardware that runs this business process?
18. Is there an organized project team that is implementing this business process? Who are they? How can you contact them?
19. Is there a method in place to identify open issues and resolve them? Where is this documented?

As is demonstrated by the list above, there is a significant amount of knowledge and intelligence that needs to be collected and used to connect business networks and business processes together. Traditionally this information has not been aggregated, documented and organized in a reusable manner or repository. When consultants, developers, business analysts or architects leave the company or are made redundant, and there is not a centralized repository containing this information the very success and sustainability of the business is at risk.

Documented business processes, SOA and web services offer strategies, technologies and methodologies for reusing development work, but there also needs to be a strategy for locating non-technical information. These processes need to have the assignment of people's names, contact information, physical locations, reporting structuring, servers, test data samples and documentation. A genius programmer is of little value if his/her work can not be found, reused, understood and exploited for the benefit of the company.

SAP's Enterprise Service Repository, Netweaver XI/PI, composite applications, IDocs, workflow and other technologies are examples of reusable intellectual assets and methodologies. These same kinds of strategies now must be extended into the B2B / EDI space to facilitate the rapid and efficient connection of trading partners in your business network.

How would you know who to contact in the EDI department of your suppliers to facilitate electronic data exchanges? Who is their boss? Where would you find the owner of the JIT delivery business process of your key suppliers? How do you know if this process is already in use somewhere else in the company? Is another division of the company already using EDI standards, messages, APIs and business processes that you can reuse? How do you find them?

Reuse, and optimizing the value of all development projects is absolutely necessary in times of shrinking sales, profits and fewer IT resources. There needs to be an effective way of organizing, sorting, searching and reusing B2B maps, integration projects, previous connections, existing data exchanges, integrations, APIs etc. It is these very challenges that I believe are being addressed now by SAP's Business Network Transformation strategies.

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

EDI, B2B and Business Network Transformation in Today's Economy

If there was ever a need for an excuse to transform business networks, the latest sales reports from the automotive industry can provide it. Things must change. As the saying goes, "If you always do, what you have always done, you will always get, what you have always gotten." The current business model is unsustainable. Companies need to scrutinize every expense and activity with the question - Does this expense or activity add value to my core business or is it a commodity item? Commodity items include any activities or expenses that are required to operate a business, but do not offer any competitive differentiators or specific value above and beyond what every other business has.

Electricity is an example of a commodity item. Yes, your company needs electricity, but you can buy it for a monthly fee from a utility without having to invest, operate or maintain your own personal electrical power plant. What other services does a company need that can be purchased as a service for less money than building and maintaining it in-house? Can you save money and invest in other areas that have much higher returns?

Today, companies are looking at each activity and expense and asking themselves the question - Is this a commodity item? Are there managed services companies (utilities) that can do a better job and for less money due to their expertise and economies of scale?

Here is another way of looking at it - ACME company designs, manufactures and markets the best widgets in the world. They are very good at designing and marketing widgets. ACME also runs a customer support center, a trucking company, an HR department, a payroll department, manufacturing operations, an IT department, an EDI department, and a facilities maintenance department , but ACME is not recognized or valued for any of these departments. Their competitive differentiators are designing and marketing the best widgets.

If ACME could find a higher quality and less expense way to run HR, customer support, marketing, manufacturing, IT, EDI, facilities, logistics and transportation, etc., then they could use those savings to further invest in developing the areas where they have competitive differentiators - designing and marketing widgets. This is not to say that these other departments are not important to your business, just the oposite - they are CRITICAL! They just aren't always competitive differentiators that need to be developed and maintained in-house.

If ACME chooses to focus on their competitive differentiators and use managed service providers for their non-core services, then they must have a solid business network strategy in place. This strategy must include an effective way of managing distributed services. This includes having real-time visibility into the services performed, accurate and real-time communications with the managed service providers. It will not be effective to introduce slow and error prone communications into an extended business network. The more you use managed service providers the faster and more accurate your communications must be in order to effectively manage it. The vision of a successful business network only works if the business network "connections" work.

OK - how do you ensure visibility, accurate and real-time communications with managed services providers in your business network? You need to automate and integrate your business processes with electronic data exchanges. The traditional approach is EDI, but flat file, XML, CSV and any other electronic data exchange can be used. You can not introduce a series of human interactions into a business process and maintain an accurate, consistent and real-time exchange of business data. It must be automated and integrated.

A follow-up question now - Are the electronic data exchanges, that automation and integration enable, a core value to your company, or a commodity service in the same manner as a phone service or the internet?

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