This week I read an article called Too Big to Manage?, in the Wall Street Journal, The Journal Report, Monday, October 26, 2009. The subtitle is Some companies are simply too complex to be run efficiently. The focus of the article was complexity, and how complexity can overwhelm management. I have been there. I have been an executive that was completely overwhelmed by the complexity of managing all the various components and competing interests in a fast growing high tech company. This article resonated with me. In hindsight I recognized that much of the complexity was unnecessary and not core to the success of my company.
One of the solutions, listed in the article, that helps companies reduce complexity is to, "Outsource or spin off nonstrategic services. Many companies have taken entire business processes off of their books, such as IT, finance, logistics and human resources, thus simplifying their internal operations dramatically."
In my experience, R&D, product delivery (software development and professional services), marketing, sales and customer service were core, but just about everything else should have been outsourced.
In this article I identify the large number of people and departments that get involved in even a simple EDI implementations. Traditional EDI is complex and resource intensive. Many large companies have directly contacted me this year to ask my advice on outsourcing EDI as a nonstrategic service. It is required, but not as an internal effort. Many companies are better served by simply connecting their SAP ERP to an SAP-centric EDI Exchange and letting all the complexity be managed in an external cloud computing environment.
Focus your IT brain power on something that will actually produce additional value for the company. Traditional EDI and B2B are no longer considered competitive differentiators. All large companies have these capabilities. Therefore, the advantages are now found only in making it less expensive, simpler and more widely used, all of which are accomplished by outsourcing to a quality EDI service provider.
SAP has recently invested in and become a co-owner of an EDI Exchange for SAP users. Why? The same reasons - the believe they can create an EDI Exchange in a cloud computing environment that can provide EDI services faster, simpler and for less money than SAP users could do in-house.
I look forward to your thoughts and comments.
************************************************
Author Kevin Benedict
Independent EDI, B2B and Mobile Computing Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com/
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
Tuesday, October 27, 2009
Monday, October 26, 2009
SAP Event Management, EDI and Cloud Computing
SAP Event Management (SAP EM) is a powerful solution that I believe will be increasingly popular as companies continue the trend of globalization and employing extended multi-enterprise supply chains and contract manufacturers. Here is a brief description of SAP EM that comes from SAP's wiki:
With the SAP® Event Management application your company can monitor and manage events across your distributed processes involving partners, inventories and assets. It captures events from your system and your partners' systems, analyzes them against it's predefined plan and alerts or workflows a response to the required people to react when deviations are found. It comes integrated with SAP® NetWeaver BI and SAP® Auto-Id Infrastructure (RFID enabled scenarios).
RFID and auto-id solutions using both static systems and mobile handheld computers collect data that are used to report on the shipping status and assembly line progress of various components. This data is fed into SAP EM via EDI or B2B data exchanges.
Multi-enterprise supply chains are inherently risky as you add more variables that can go wrong. Each participant in a multi-enterprise supply chain has its own supply chain and priorities that can become a dependency to your project's success. Include cultural issues, different languages, geo-political uncertainties, taxes, currency exchange rates, laws and regulations to the mix and you have a recipe for excitement and drama.
The management of an extended and multi-enterprise supply chain requires a much higher and advanced level of automation, visibility and management than ever before. SAP EM is a solution well positioned for this role.
I see extended multi-enterprise supply chains as nearly an entity in itself. It is a shared community effort, an organism with many different living parts, a process that requires cooperation from all parties to be successful. In many cases, I think it would be better if SAP EM were a hosted solution in a cloud computing environment that supported the extended multi-enterprise supply chain community, rather than being owned by one particular participant in the process.
Let's now discuss for a moment the role EDI and B2B messages plays in the SAP EM environment. All participants in this extended multi-enterprise supply chain need to be sharing data that informs the other participants as to the progress, schedules and status of their segment of the supply chain process. They need to receive orders, acknowledge the order, order parts, receive parts, manufacture products, ship products, provide advanced shipping notices, invoice etc. This is where EDI and B2B messages come in.
EDI is structured data that is documented in a standardized manner and shared between trading partners. This structured data can be called EDI or B2B (business-to-business) data exchanges. I will use the term EDI to cover both areas. This EDI data is what the participants of the extended multi-enterprise supply chain (I will make up an acronym - EMESC) send to the SAP EM to communicate status and other business data necessary for the supply chain's success.
In the same manner as SAP EM seems to be best suited for a SaaS model in a cloud computing environment because it is a shared process by a community of members, I think the EDI/B2B data exchanges should also be an extension of the EMESC. It does not seem to make sense to have one of the many participants be responsible for the integration, development, operations and support of all participant's EDI exchanges. This responsibility should be owned by the same SaaS provider that supports the hosted SAP EM in a cloud computing environment.
I find the entire concept of SAP Event Management as a solution for tracking the entire supply chain fascinating. It has the same capability to alter the landscape of traditional supply chain management as does Business Network Transformation or SAP EDI in a cloud.
************************************************
Author Kevin Benedict
Independent EDI, B2B and Mobile Computing Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com/
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
With the SAP® Event Management application your company can monitor and manage events across your distributed processes involving partners, inventories and assets. It captures events from your system and your partners' systems, analyzes them against it's predefined plan and alerts or workflows a response to the required people to react when deviations are found. It comes integrated with SAP® NetWeaver BI and SAP® Auto-Id Infrastructure (RFID enabled scenarios).
RFID and auto-id solutions using both static systems and mobile handheld computers collect data that are used to report on the shipping status and assembly line progress of various components. This data is fed into SAP EM via EDI or B2B data exchanges.
Multi-enterprise supply chains are inherently risky as you add more variables that can go wrong. Each participant in a multi-enterprise supply chain has its own supply chain and priorities that can become a dependency to your project's success. Include cultural issues, different languages, geo-political uncertainties, taxes, currency exchange rates, laws and regulations to the mix and you have a recipe for excitement and drama.
The management of an extended and multi-enterprise supply chain requires a much higher and advanced level of automation, visibility and management than ever before. SAP EM is a solution well positioned for this role.
I see extended multi-enterprise supply chains as nearly an entity in itself. It is a shared community effort, an organism with many different living parts, a process that requires cooperation from all parties to be successful. In many cases, I think it would be better if SAP EM were a hosted solution in a cloud computing environment that supported the extended multi-enterprise supply chain community, rather than being owned by one particular participant in the process.
Let's now discuss for a moment the role EDI and B2B messages plays in the SAP EM environment. All participants in this extended multi-enterprise supply chain need to be sharing data that informs the other participants as to the progress, schedules and status of their segment of the supply chain process. They need to receive orders, acknowledge the order, order parts, receive parts, manufacture products, ship products, provide advanced shipping notices, invoice etc. This is where EDI and B2B messages come in.
EDI is structured data that is documented in a standardized manner and shared between trading partners. This structured data can be called EDI or B2B (business-to-business) data exchanges. I will use the term EDI to cover both areas. This EDI data is what the participants of the extended multi-enterprise supply chain (I will make up an acronym - EMESC) send to the SAP EM to communicate status and other business data necessary for the supply chain's success.
In the same manner as SAP EM seems to be best suited for a SaaS model in a cloud computing environment because it is a shared process by a community of members, I think the EDI/B2B data exchanges should also be an extension of the EMESC. It does not seem to make sense to have one of the many participants be responsible for the integration, development, operations and support of all participant's EDI exchanges. This responsibility should be owned by the same SaaS provider that supports the hosted SAP EM in a cloud computing environment.
I find the entire concept of SAP Event Management as a solution for tracking the entire supply chain fascinating. It has the same capability to alter the landscape of traditional supply chain management as does Business Network Transformation or SAP EDI in a cloud.
************************************************
Author Kevin Benedict
Independent EDI, B2B and Mobile Computing Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com/
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
Monday, October 19, 2009
Switching from Traditional EDI and Going Green
It appears I am not the only one talking about how EDI helps companies go green. Several weeks back I wrote the article called Going Green with SAP EDI and e-Invoicing, and today I read this announcement, Moving towards a Green Future - SANYO Switches to EDI On-Demand.
SANYO Component Europe GmbH, the leading supplier of industrial batteries for hybrid vehicles and other electronic automotive components, is switching its EDI communications with business partners to an on-demand EDI service (using a cloud computing model) that is "powered by SAP" which is fully in line with its green "Think GAIA" corporate vision.
It appears that SANYO sees switching from a traditional EDI model to an in the cloud computing model as helping them achieve their goals of accelerating the introduction of innovative and ecologically friendly technologies, and to become a leading supplier of industrial batteries for the automobiles of the future. The previous solution, an in-house EDI middleware solution, was too expensive to maintain and to continue adding new trading partners and complex EDI requirements.
Let's attempt to interpret this announcement. SANYO likely has a new supply chain, new customers and new logistics partners for these products. That means several new EDI implementation projects and EDI/B2B on-boarding initiatives. That translates into lots of expensive work and a long term commitment to the traditional in-house model of EDI if done internally. Many companies pause before starting these kinds of costly initiatives and ask themselves if the traditional approach of running an EDI system and staffing their own internal EDI department is the best strategy for EDI and B2B support in the long term. Obviously SANYO decided that it was a good time to switch to the cloud computing model for EDI/B2B promoted by SAP.
For related articles read:
************************************************
Author Kevin Benedict
Independent EDI, B2B and Mobile Computing Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
SANYO Component Europe GmbH, the leading supplier of industrial batteries for hybrid vehicles and other electronic automotive components, is switching its EDI communications with business partners to an on-demand EDI service (using a cloud computing model) that is "powered by SAP" which is fully in line with its green "Think GAIA" corporate vision.
It appears that SANYO sees switching from a traditional EDI model to an in the cloud computing model as helping them achieve their goals of accelerating the introduction of innovative and ecologically friendly technologies, and to become a leading supplier of industrial batteries for the automobiles of the future. The previous solution, an in-house EDI middleware solution, was too expensive to maintain and to continue adding new trading partners and complex EDI requirements.
Let's attempt to interpret this announcement. SANYO likely has a new supply chain, new customers and new logistics partners for these products. That means several new EDI implementation projects and EDI/B2B on-boarding initiatives. That translates into lots of expensive work and a long term commitment to the traditional in-house model of EDI if done internally. Many companies pause before starting these kinds of costly initiatives and ask themselves if the traditional approach of running an EDI system and staffing their own internal EDI department is the best strategy for EDI and B2B support in the long term. Obviously SANYO decided that it was a good time to switch to the cloud computing model for EDI/B2B promoted by SAP.
For related articles read:
************************************************
Author Kevin Benedict
Independent EDI, B2B and Mobile Computing Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
Friday, October 16, 2009
Upfront SAP EDI Costs - Or Pay as You Go
Sometimes I don't write very well. In this article from NPR's Jon Hamilton dated October 16, 2009 he reports that it take only about 1/2 second to transform a thought into words. Sometimes it only takes 3/4 of a second for my thoughts to end up on a blog. I apologize. An article I recently wrote called EDI - $500,000 Invested and it Still Doesn't Work generated quite a few comments that focused on issues related to poor project management. Since that was not a focus of my article, I must conclude I wrote poorly and did not make my point. As I am not one to give up easily, I will try again.
In traditional EDI, in a medium to large size enterprise, one must spend considerable money up front simply to purchase the EDI translator and set-up all the associated hardware, software and integration processes to support it. A company must also invest considerable amounts of money into staffing an EDI team, or hiring consultants, and creating a project plan. EDI standards must be considered, trading partner's surveyed, data formats reviewed, ERP integration strategies determined and communication protocols selected. All of this work is done before there is an ROI. That was the point readers of my original article did not get. So again, all of the infrastructure, licenses, staffing and meeting after meetings must be done in advance of any ROI in the traditional way of running an internal EDI/B2B department.
The new alternative, is to Pay-as-You-Go for EDI and B2B integrations and support it in a cloud computing environment so you can immediately begin receiving a ROI. As I have mentioned earlier, many IT departments are being told to demonstrate a 90 day ROI on any IT investments or don't bother submitting the request. You cannot show a 90 day ROI if you choose to implement a traditional in-house EDI system and department. The ROI is a multi-year effort in most cases. Therefore, IT and business units must either not implement new EDI in the traditional mode, or find an alternative manner of implementing EDI that shows a much quicker ROI.
SAP understands this point They invested in an EDI and e-Invoicing Exchange for SAP users that functions in a cloud computing environment with a subscription business model. All of the EDI systems, global e-Invoicing processes, EDI standards, communication protocols, help desks and EDI expertise is already set-up and available in a monthly subscription model. You only start paying a set-up and service fee when you implement a new EDI or B2B trading partner's processes. You don't need any hardware, software or EDI staff investment upfront.
This model enables you to immediately start showing an ROI. It is the new method and strategy that changing economic times demands from IT vendors.
If you would like to discuss this topic in more detail please contact me.
For related articles please read:
************************************************
Author Kevin Benedict
Independent EDI, B2B and Mobile Computing Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
In traditional EDI, in a medium to large size enterprise, one must spend considerable money up front simply to purchase the EDI translator and set-up all the associated hardware, software and integration processes to support it. A company must also invest considerable amounts of money into staffing an EDI team, or hiring consultants, and creating a project plan. EDI standards must be considered, trading partner's surveyed, data formats reviewed, ERP integration strategies determined and communication protocols selected. All of this work is done before there is an ROI. That was the point readers of my original article did not get. So again, all of the infrastructure, licenses, staffing and meeting after meetings must be done in advance of any ROI in the traditional way of running an internal EDI/B2B department.
The new alternative, is to Pay-as-You-Go for EDI and B2B integrations and support it in a cloud computing environment so you can immediately begin receiving a ROI. As I have mentioned earlier, many IT departments are being told to demonstrate a 90 day ROI on any IT investments or don't bother submitting the request. You cannot show a 90 day ROI if you choose to implement a traditional in-house EDI system and department. The ROI is a multi-year effort in most cases. Therefore, IT and business units must either not implement new EDI in the traditional mode, or find an alternative manner of implementing EDI that shows a much quicker ROI.
SAP understands this point They invested in an EDI and e-Invoicing Exchange for SAP users that functions in a cloud computing environment with a subscription business model. All of the EDI systems, global e-Invoicing processes, EDI standards, communication protocols, help desks and EDI expertise is already set-up and available in a monthly subscription model. You only start paying a set-up and service fee when you implement a new EDI or B2B trading partner's processes. You don't need any hardware, software or EDI staff investment upfront.
This model enables you to immediately start showing an ROI. It is the new method and strategy that changing economic times demands from IT vendors.
If you would like to discuss this topic in more detail please contact me.
For related articles please read:
- Going Green with SAP EDI and Electronic Invoicing
- Breakdown of e-Invoicing Benefits
- Converting Paper Invoices to Electronic Invoices is Required for Global E-Commerce
- The Benefits of e-Invoicing
************************************************
Author Kevin Benedict
Independent EDI, B2B and Mobile Computing Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
Tuesday, October 13, 2009
The True Costs of EDI
In this article the true costs of implementing EDI are discussed. The costs go way beyond that which is usually reflected on the IT budget spreadsheet. Why? The business unit must be involved as are people involved up and down the supply chain and other impacted departments. For a true ROI on EDI it is important to consider the points made in this article.
************************************************
Author Kevin Benedict
Independent EDI, B2B and Mobile Computing Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
************************************************
Author Kevin Benedict
Independent EDI, B2B and Mobile Computing Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
Monday, October 12, 2009
EDI - $500,000 Invested and it Still Doesn't Work
It is very important these days for IT and business departments to get a fast return on their investment. I have heard business managers mandate 90 day ROIs or the IT project will not be approved. This is a big challenge for EDI vendors. Why? Let me share some experiences.
Many EDI translators are expensive. When you add up the license costs, the various servers, development, testing and production, consulting, implementation, training, hardware, communications, mappers, EDI standards, ERP adaptors, integration development etc, it is not unusual for all of this to add up to over $500,000. Here is the big problem - it still doesn't provide an ROI after all of that investment. The $500,000 is just to get you prepared.
Prepared, that is, for the start of your expensive and long multi-year trading partner implementation project. This could be more expensive than the original investment. The ROI will only start once data is moving in production through the EDI and integration system between you and your trading partner. Everything that you spend money on that does not move production data between you and your trading partner can not provide an ROI.
Here is an alternative to consider. Skip all of the software, hardware, integration code development, consultants, etc, and simply use a managed EDI service. Only pay for actual implementations and production services. That way every penny that you spend is for an ROI, not to prepare you for an eventual ROI.
SAP co-owns their own EDI managed service for SAP users that runs in a cloud computing environment so you have no hardware or software to purchase and maintain. You only pay for connecting to your trading partners and supporting a production environment. Something to consider.
If you would like to discuss this topic in more detail please email me.
For related articles please see:
Many EDI translators are expensive. When you add up the license costs, the various servers, development, testing and production, consulting, implementation, training, hardware, communications, mappers, EDI standards, ERP adaptors, integration development etc, it is not unusual for all of this to add up to over $500,000. Here is the big problem - it still doesn't provide an ROI after all of that investment. The $500,000 is just to get you prepared.
Prepared, that is, for the start of your expensive and long multi-year trading partner implementation project. This could be more expensive than the original investment. The ROI will only start once data is moving in production through the EDI and integration system between you and your trading partner. Everything that you spend money on that does not move production data between you and your trading partner can not provide an ROI.
Here is an alternative to consider. Skip all of the software, hardware, integration code development, consultants, etc, and simply use a managed EDI service. Only pay for actual implementations and production services. That way every penny that you spend is for an ROI, not to prepare you for an eventual ROI.
SAP co-owns their own EDI managed service for SAP users that runs in a cloud computing environment so you have no hardware or software to purchase and maintain. You only pay for connecting to your trading partners and supporting a production environment. Something to consider.
If you would like to discuss this topic in more detail please email me.
For related articles please see:
Staffing for an internal EDI department
EDI Business Network Transformation
EDI data, mappings and other intellectual assets
Considerations for outsourcing EDI
Documenting EDI data requirements
Creating an EDI Implementation Guide
************************************************
Author Kevin Benedict
Independent EDI, B2B and Mobile Computing Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com/
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
How EDI and B2B Connections Can Destroy Your Company
I realize the title of this article may be a bit dramatic, but it is true. I have seen companies that desparately needed to change their business model, upgrade their SAP ERP systems and implement new business processes, suddenly halt this effort due to the unexpected and unanticipated requirements to replace all of their existing EDI and B2B integrations.
Think of it this way, have you ever needed to move the entertainment system in your house? The mass of dust covered cords, wires and cables hidden behind it can be daunting. You may hesitate to even move the entertainment system out of fear that something will become disconnected and not work. It is the same process multiplied by 100,000 with your trading partners and their integration scripts.
Let's say you have 1,000 suppliers. If you are going to upgrade, change or alter the data model of your ERP, it is highly likely you are going to quickly start breaking mission critical EDI data exchanges between you and your suppliers. This tends to enrage just about everyone in your company and at your suppliers.
OK, there is a challenge here, but there is also a very desparate need to upgrade or change the ERP so you can take advantage of all kinds of new business processes, technologies and application features. The problem is the ERP folks and the business managers didn't talk to the EDI department when they purchased the new upgrade. Now the ERP is suppose to be functioning and in production in 5 months, but the EDI department is already buried under just routine operations and support.
At this point things get really crazy. The business managers start blaming the EDI department for obstructing progress, innovation and business transformation. The EDI team just looks up from their terminals and says, "huh?"
Now the CIO is in hot water. She calls the EDI Manager to her office and asks, "How come you are stopping the company from meeting their quarterly and yearly goals?" The EDI Manager says, "Not our fault. There is 20 years worth of custom and undocumented integration code that an upgrade to the ERP will break. Has nothing to do with us. The ERP folks are breaking what already works."
The story gets darker. The CIO walks the green mile to the CEO's office and says there is 20 years worth of EDI integration code and scripts that need to be replaced, and it will take 2 years worth of unbudgeted development to re-integrate and test all of these EDI integrations. The CEO steps around his desk and quietly shuts the door of his office.
When the CEO's door reopens 3 hours later, the CIO has been tasked with re-introducing manual spreadsheets, phone calls, emails and faxes to the suppliers. This step 15 years back in time is needed to keep the ERP upgrade on schedule without EDI interference.
What the 3 hour meeting in the CEO's office did not fully acknowledge or plan for is how much the supply chain, logistics department and customers would be effected by this return to manual systems. The downward spiral begins.
I have seen this process unveiled before my very own eyes. How can it be avoided? There needs to be a plan in advance to create a layer of separation between your ERP and your EDI translators and trading partners. This layer is a change management insurance policy. Custom EDI integration scripts need to be replaced with one integration per business process. This single integration needs to support all varieties of Purchase Orders, Invoices and other EDI messages. You cannot have a new integration to your ERP for every trading partner's custom data file. The EDI integration needs to be a standardized process that connects to a canonical data model associated with the EDI translator. This is usually only possible if you are using a manage service from a large EDI/B2B hub. The alternative, is the situation documented above.
This is one of those things that no one likes to plan for, but the business depends on it.
If you would like to discuss this topic in more detail please email me.
************************************************
Author Kevin Benedict
Independent EDI, B2B and Mobile Computing Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com/
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
Think of it this way, have you ever needed to move the entertainment system in your house? The mass of dust covered cords, wires and cables hidden behind it can be daunting. You may hesitate to even move the entertainment system out of fear that something will become disconnected and not work. It is the same process multiplied by 100,000 with your trading partners and their integration scripts.
Let's say you have 1,000 suppliers. If you are going to upgrade, change or alter the data model of your ERP, it is highly likely you are going to quickly start breaking mission critical EDI data exchanges between you and your suppliers. This tends to enrage just about everyone in your company and at your suppliers.
OK, there is a challenge here, but there is also a very desparate need to upgrade or change the ERP so you can take advantage of all kinds of new business processes, technologies and application features. The problem is the ERP folks and the business managers didn't talk to the EDI department when they purchased the new upgrade. Now the ERP is suppose to be functioning and in production in 5 months, but the EDI department is already buried under just routine operations and support.
At this point things get really crazy. The business managers start blaming the EDI department for obstructing progress, innovation and business transformation. The EDI team just looks up from their terminals and says, "huh?"
Now the CIO is in hot water. She calls the EDI Manager to her office and asks, "How come you are stopping the company from meeting their quarterly and yearly goals?" The EDI Manager says, "Not our fault. There is 20 years worth of custom and undocumented integration code that an upgrade to the ERP will break. Has nothing to do with us. The ERP folks are breaking what already works."
The story gets darker. The CIO walks the green mile to the CEO's office and says there is 20 years worth of EDI integration code and scripts that need to be replaced, and it will take 2 years worth of unbudgeted development to re-integrate and test all of these EDI integrations. The CEO steps around his desk and quietly shuts the door of his office.
When the CEO's door reopens 3 hours later, the CIO has been tasked with re-introducing manual spreadsheets, phone calls, emails and faxes to the suppliers. This step 15 years back in time is needed to keep the ERP upgrade on schedule without EDI interference.
What the 3 hour meeting in the CEO's office did not fully acknowledge or plan for is how much the supply chain, logistics department and customers would be effected by this return to manual systems. The downward spiral begins.
I have seen this process unveiled before my very own eyes. How can it be avoided? There needs to be a plan in advance to create a layer of separation between your ERP and your EDI translators and trading partners. This layer is a change management insurance policy. Custom EDI integration scripts need to be replaced with one integration per business process. This single integration needs to support all varieties of Purchase Orders, Invoices and other EDI messages. You cannot have a new integration to your ERP for every trading partner's custom data file. The EDI integration needs to be a standardized process that connects to a canonical data model associated with the EDI translator. This is usually only possible if you are using a manage service from a large EDI/B2B hub. The alternative, is the situation documented above.
This is one of those things that no one likes to plan for, but the business depends on it.
If you would like to discuss this topic in more detail please email me.
************************************************
Author Kevin Benedict
Independent EDI, B2B and Mobile Computing Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com/
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
Wednesday, October 7, 2009
Mobile and Location Based Services and EDI Integration
Location based services are not usually associated with EDI or B2B integrations, however, I am considering a scenario where that might change. By location based services we generally think of mobile phones, Smart Phones and handheld computers. We think of various marketing and informational programs that can target the phones of people within a specific distant of a business. For example, you want Pizza so you open Safari on your iPhone and type in the word pizza. It immediately shows you on a map the location of businesses that serve pizza. By tapping on the screen up pops their address, phone number and website. How does EDI fit into that?
Many large companies have central ERPs (enterprise resource planning) software that manages their business. ERPs manage just about everything from new employee hires, transportation, shipping and manufacturing. Sometimes the information you need in a "location based services" application is kept on one or more ERPs. This may involve real-time A2A (application-to-application) or EDI integration to access this information.
In this article there is an interesting example of LBSs from Subway (the sandwich folks) and a scenario with a grocery store chain.
************************************************
Author Kevin Benedict
Independent EDI, B2B and Mobile Computing Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com/
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
Many large companies have central ERPs (enterprise resource planning) software that manages their business. ERPs manage just about everything from new employee hires, transportation, shipping and manufacturing. Sometimes the information you need in a "location based services" application is kept on one or more ERPs. This may involve real-time A2A (application-to-application) or EDI integration to access this information.
In this article there is an interesting example of LBSs from Subway (the sandwich folks) and a scenario with a grocery store chain.
************************************************
Author Kevin Benedict
Independent EDI, B2B and Mobile Computing Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com/
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
Tuesday, October 6, 2009
Implementing, Organizing and Managing SAP EDI
For any company that is considering a new EDI implementation and is struggling to understand EDI and what it takes to develop an EDI department, the links I have provided below should prove useful.
The first question a company will want to ask themselves is why support EDI or other B2B data exchanges at all? What is the purpose and business value? EDI and B2B systems, integrations and support are expensive and time consuming. What is the expected ROI? Often customers demand EDI support, and the business will quickly see the value in implementing EDI (electronic data interchange) with their suppliers and logistics partners The reason you want to document the purposes is that it helps focus support and encourage perserverance during challenging implementations.
If your company can identify why supporting EDI is important, then the second question is should EDI be supported internally or can it be subscribed to as a service (SaaS or IaaS models)? EDI systems, staffing, development, integrations, implementations, operations and support are very expensive. The company really must understand the business value upfront, and then decide if this huge multi-year investment is worthwhile to support internally. Not only is it expensive, but it will require your best IT developers and brains to get everything working. Is this the best use of your best brains this year? If not, can you simply subscribe to an external EDI service provider that will take care of everything for a small set-up fee and a monthly service fee?
For those new to the world of EDI, or just want a refresher, the following links identify many of the tasks, challenges and issues that need to be considered and understood.
Implementing EDI
Staffing for an internal EDI department
EDI Business Network Transformation
EDI and B2B Challenges
EDI data, mappings and other intellectual assets
Considerations for outsourcing EDI
SAP's New Strategy for EDI
The Real Purpose of EDI
More on EDI Staffing
Documenting EDI data requirements
Creating an EDI Implementation Guide
If you would like to discuss any of these topics in more detail, or schedule a training class for your business please contact me.
************************************************
Author Kevin Benedict
EDI, B2B and Mobile Computing Evangelist and Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
The first question a company will want to ask themselves is why support EDI or other B2B data exchanges at all? What is the purpose and business value? EDI and B2B systems, integrations and support are expensive and time consuming. What is the expected ROI? Often customers demand EDI support, and the business will quickly see the value in implementing EDI (electronic data interchange) with their suppliers and logistics partners The reason you want to document the purposes is that it helps focus support and encourage perserverance during challenging implementations.
If your company can identify why supporting EDI is important, then the second question is should EDI be supported internally or can it be subscribed to as a service (SaaS or IaaS models)? EDI systems, staffing, development, integrations, implementations, operations and support are very expensive. The company really must understand the business value upfront, and then decide if this huge multi-year investment is worthwhile to support internally. Not only is it expensive, but it will require your best IT developers and brains to get everything working. Is this the best use of your best brains this year? If not, can you simply subscribe to an external EDI service provider that will take care of everything for a small set-up fee and a monthly service fee?
For those new to the world of EDI, or just want a refresher, the following links identify many of the tasks, challenges and issues that need to be considered and understood.
Implementing EDI
Staffing for an internal EDI department
EDI Business Network Transformation
EDI and B2B Challenges
EDI data, mappings and other intellectual assets
Considerations for outsourcing EDI
SAP's New Strategy for EDI
The Real Purpose of EDI
More on EDI Staffing
Documenting EDI data requirements
Creating an EDI Implementation Guide
If you would like to discuss any of these topics in more detail, or schedule a training class for your business please contact me.
************************************************
Author Kevin Benedict
EDI, B2B and Mobile Computing Evangelist and Consultant
www.linkedin.com/in/kevinbenedict
http://b2b-bpo.blogspot.com
http://mobileenterprisestrategies.blogspot.com/
I am a loose canon. No individual or company, no matter how much I try, is willing to be responsible for my comments. So alas, they are mine alone.
************************************************
EDI Audits and ROIs for Supply Chain Management
EDI and B2B systems are expensive and time consuming to setup. A positive ROI (Return on Investment) is realized only after economies of scale are reached. This may come after the successful implementation of 10 high volume trading partners or 1000 low volume. The exact ROI figure depends on the initial investment and the expected returns from each successful implementation. What is known is that the faster, and simpler the implementation the less expensive it will be. Also, the more that the initial implementation work can be reused and leveraged, the more cost effective it will be and the sooner the ROI will be recognized.
In order to maximize the ROI, it is necessary that we prioritize our tasks and efforts. Which trading partners do we implement with first, high volume or high value? Where is the greatest potential savings or returns? One of the first steps to implementing our strategy is to audit our internal business processes, and then to audit our external business processes that touch our trading partners.
The following list contains questions that should be resolved before and during EDI and B2B system implementations:
Additional Issues:
1. The addition of new data to the database to meet standards requirements.
2. The use of tables to cross-reference part numbers with trading partners.
3. A change in review or approval processes.
4. The development of a data link between the application program and the translation package.
5. Electronic linkages to the database for departments that formerly received manual reports.
6. The need to bridge between applications if multiple departments use the same information.
If you would like to discuss this topic in more detail please contact me.
In order to maximize the ROI, it is necessary that we prioritize our tasks and efforts. Which trading partners do we implement with first, high volume or high value? Where is the greatest potential savings or returns? One of the first steps to implementing our strategy is to audit our internal business processes, and then to audit our external business processes that touch our trading partners.
The following list contains questions that should be resolved before and during EDI and B2B system implementations:
- What information is exchanged between business partners? This includes formal documents such as purchase orders, invoices, etc., as well as informal documents and communications such as messages, memos, phone calls and faxes. All methods of communication have costs associated with them.
- How and where is the information initiated; manual input, screen entry, or computer generated?
- Where can time be saved?
- How much labor savings could be recognized?
- What is the internal flow of information?
- Currently - How many copies are produced, and in what format?
- Who receives copies and why?
- Are these copies stored and for how long?
- What control and reporting measures are used—status reporting, audit trails, security safeguards?
- Who needs to be involved in the work flow? Who approves the business documents or transactions and how?
- What specific information is needed for current application programs—form of data, data flow between applications, entry of data?
- What information is available from application programs?
- What results are produced?
- What is the format and structure of the data output?
- How does the speed of processing documents effect the business? Some are time sensitive, others not so much.
Additional Issues:
1. The addition of new data to the database to meet standards requirements.
2. The use of tables to cross-reference part numbers with trading partners.
3. A change in review or approval processes.
4. The development of a data link between the application program and the translation package.
5. Electronic linkages to the database for departments that formerly received manual reports.
6. The need to bridge between applications if multiple departments use the same information.
If you would like to discuss this topic in more detail please contact me.
Subscribe to:
Posts (Atom)