Lewin: SEEBURGER is focused on helping companies implement Information Driven Supply Chains (IDSC). Companies want and need to have a much closer collaboration with their customers and suppliers resulting in a significant competitive advantage. This closer collaboration means much more than just exchanging documents. The IDSC utilizes a common platform and incorporates a comprehensive trading partner management and enablement strategy. This process centric solution relies on exception management to minimize human intervention. In addition, a full layer of visibility, both from the technical and the business perspective is provided. This allows all internal and external members of the supply chain to have access to all relevant information of the business process.
How has this focus changed in the last 2 years?
Lewin: Over the past two years, B2B integration has evolved from a very tactical solution to a strategic solution that touches all aspects of the business. Implementing a new B2B solution means examining the current processes and outlining how the business should be structured in the next 3-5 years. SEEBURGER is working with many Fortune 500 as well as mid market companies to develop the ideal solution that provides a competitive advantage in their market. Doing EDI only is no longer enough. Progressive companies are looking at how to more tightly interact with their customers and suppliers, regardless of the technology found at their partners.
What are your current initiatives?
Lewin: SEEBURGER does a lot of work with global organizations who want to consolidate their IT strategies and need a trading platform that meets the wide variety of requirements in the global economy. Our goal is to provide one platform that allows for 100% trading partner integration and management regardless of the technical capabilities found at the partner. Because SEEBURGER's strategy has always been to build our technology internally, we are able to provide a true one platform solution instead of one that has been cobbled together via acquisition. The result is a much more robust, stable and faster to implement solution.
How has the market for EDI changed with the impact of the Internet?
Lewin: The internet has opened up many additional opportunities for connectivity between organizations. In addition, it makes the sharing of information much faster and less costly. But the internet has not replaced the need to have very strong and well thought out internal business processes. Getting the data is not the major challenge. The key is what to do with the data once you have it. What processes are followed so the data is available in the right format to all of the different systems within an organization. In addition, providing a business level view in real time of the data delivers significant value to the organization.
What are the greatest challenges for your customers?
Lewin: Customers are still finding it very challenging to coordinate internal business processes and goals with their trading partners' capabilities and strategies.
How are you helping your customers address these challenges?
Lewin: SEEBURGER brings experienced technical and business consultants who are able to architect and then implement the best solution for each customer. Our history of working with global customers who have wide varieties of requirements means we bring a very deep level of B2B knowledge to the table. In addition, our extensive knowledge of ERP systems allows us to craft a solution that complements the customers system architecture.
Who should pay for testing?(What are the components of the testing phase?)
Lewin: We find it best to distinguish between platform testing and interface testing. Platform testing involves validating the technical infrastructure and process architecture while interface testing is focused on validating the map interface programs that ride on top it.
Platform Testing: Viewed from the outside in, platform testing involves establishing and testing connectivity between the middleware and the client's trading community, usually involving communications channels such as FTP, VAN or AS2. From there all of the process architecture pathways must be validated in concert with different trading partner metadata configurations to stress functions such as classification & routing, splitting/merging/batching, 997 reconciliation, and error notifications, etc. Back-end application connectivity also needs to be checked whether you're using application specific adapters for systems like SAP or Oracle or traditional file-port mechanisms.
Platform testing is usually included as part of the initial deliverables package, while interface testing involves significant system inter-dependencies that make this more of a shard effort.
Interface Testing Interface testing typically varies depending upon the migration strategy and the scope of deployment. If the project calls for a simple "rip and replace" of existing EDI middleware, then the trading partner & ERP endpoints don't change much, if at all. This allows you to develop updated mappings that leverage history already embodied in the legacy environment. You can then test these interfaces by running them through both environments in parallel and "diffing" the output for unexpected variances during QA.
Interface Testing -ERP Consolidation: For Global ERP consolidations or large scale new partner enablement programs, however, the testing responsibilities are more broadly distributed and can often become complex.
Take the example of a new ERP deployment. If you view integration as a coin that bridges the internal requirements of a new ERP system to the external requirements of a trading partner's EDI guidelines, then Seeburger can helpfully represent the trading partners' requirements all the way through to the "tails" side of that coin. However, there must be someone on the client side who understands the new ERP deeply enough to definitively represent what the "heads" side of that coin should look like to seamlessly interoperate with the new system. If you have that, then the mapping and testing will be of much higher quality initially. If you don't, then you will pay for that later during integration testing or production in the form of late changing interface refinements. The joint collaboration that takes place during design facilitation therefore makes the most meaningful impact to successful interface testing and lower costs over time.
For this reason, for large scale map acceleration programs, we typically begin with a design facilitation segment that results in a set of agreed upon map interface specifications, which are combined with trading partner specific sample data and test scenarios as input to development.
We develop the interfaces to conform to these specifications and then validate them as "unit test" complete against the test scenarios and sample data provided. From there, we work with the customer's application specialists who apply the maps to their back-end system in follow-on integration test scenarios and provide us with refinement feedback as they work them through to production.
Development customarily includes the unit testing validation steps and we also commonly provide for refinement iterations after unit test, to allow for last minute tweaks to design specifications that often only show up during integration testing.
Alternatively, it is also quite common for customers to work with us in a purely advisory capacity where we help them establish their own map acceleration program that leverages Seeburger's development and best practices training to adapt our map acceleration methodology to the customer environment and leverage on their own with internal resources.
Either way, regardless of the map development model, it is important to methodically incorporate to rigorous design and testing plan into the mix.
How do you categorize 'good' testing versus 'bad' or useless testing?
Lewin: Testing must be broad to be effective. Again, if you're only "swapping out the middle" and the two end-points remain the same, then you can run new transactions through both environments in parallel and "diff" the output to ensure higher quality. For new partners or when the backend is changing, however, you need to poke around at everything.
We see a lot of customers that simply plan to take their most common trading scenario and run it through 5,000 times to call that testing. Depending upon the distribution of data elements within the content, this may validate and stress the environment somewhat, but happens when a credit memo or a consignment order arrives with special payment terms that must be reflected back on the invoice?
To catch "corner cases" like these requires a more holistic understanding of the overarching business process and the different pathways designed to support them. In our view, scenario based testing techniques are therefore indispensible in providing broader testing coverage and should be arrived at collaboratively with the client. Beyond that, good testing involves making sure you test with partner specific master data, with both fully and partially accepted 997 scenarios, and for performance at 110% of expected peak load as well.