1. Identify the Trading Partners
This may seem really simple. And it is. But it is not too simple for us.
We need to know who we will integrate with. Are these new contacts that have never worked with our company before? Or are they existing customers that will be moving to this new integrated connections? Both groups have their own sets of challenges and benefits.
Is this integration a one time event, or will we be integrating multiple trading partners using this same process? This is also important and will make a difference on how trading partner specific we want to make it.
What is the technical sophistication of the proposed trading partners? Are they going to be able to comply with our needs or will we have to do everything?
2. Identify the Data
Again, this is basic but not too basic.
We need to know if we are dealing with just orders, or if there will be invoicing and catalogs. We need to know if what type of performance we are looking for. Is this a once a month catalog load that can take hours and gets a couple or retry windows, or is this real time price comparison that need to respond in seconds.
The data and how it needs to flow will be a big piece of what we need to know.
3. Identify the Target
What is the target?
This can be taking some of your data and sending it to your Trading Partner. In this case your target is the format and communication protocol that your partner can receive.
Or it can be an internal Canonical Data Format that your systems use that you are creating from transactions received from your partner sends you.
Or it could be something else. Whatever it is, you will need to know what it is, and know all about it before you can really get started.
4. Identify the Tools and Technology
Are you using EDI? Or XML? What EAI tools are you and your partner using? SAP? WebMethods? GXS? Other?
How do complete the task will rely to a great degree on what tools and technologies you are working with. If you are an employee, you may already know this, but if you are a consultant you probably don’t. You need to find out.
5. Identify Support needs.
What happens when things go wrong? Not necessarily “horribly wrong” but just wrong. Is an error produced when the translation fails? How about creating a 850 with no line items? (no one wants to receive this.) Or if the https post or SFTP send fails, can it retry, or does it die quietly? These are questions that you need to ask and keep asking. (Please include all of the answers in your documentation.)
6. Identify the Time Frame
How long do you have to complete the integration? Is there a plan to find and fix bugs after implementation? How long is the integration planning to be used? (short term during the merger of two companies, or for as long as Walmart will buy your product?)
All of the aspects of time, time to complete, time to live and time to revisit and fix problems are good things to know, or at least have an idea about.
7. Get started, and Document your work.
Getting started, and starting the Documentation of a project should happen together. Almost at the same moment. Okay, really, at the same moment.
Documenting the answers to the questions above along with others is really the start of the integration project. And the documentation process will help you to focus your work on getting the answers that you need to finish the project.
No comments:
Post a Comment