What do you do?

Partially this is caused by the relative youth of the Information Technology fields.  Other fields with a longer history have a high degree of context.  The Butcher, Baker and Candle Stick Maker are all occupations that are so well understood that they are almost self explanatory.  A Systems Administrator or Database Administrator are relatively new and unknown, but they share something with the butcher and maker in that they sound like what they are.

The challenge of history

My first job was doing technical support, and my mother still tells people that I ‘fix computers’ for a living.  Consequently her acquaintances continue to try to get free support from me.  (Don’t even get me started on what my Father-in-law thinks I do.)  I may still have some abilities here, but this is not my job.  It is like saying that a surgeon gives people shots.  Certainly the surgeon has this skill, but this is not what he does.  (And you will have a much less painful experience if you just let the nurse give you the shot.  Trust me.)

So how do I explain what I do?  The first rule is to realize that the part of this job that are exciting to you and me, won’t really translate to conversation with your neighbour hood storekeeper, farmer, or even teacher.  So I recommend not trying.  This does not mean that I don’t talk about it.  This means that I start with what is easily understood and then work towards Integration Engineering.

Lie

Okay, that may be harsh.  But really saying, “I am a computer programmer.”  Only requires explanation if there is a follow up question.  This might come as more and more people dabble in programming.  (And really, “computer programmer” is a rather nebulous term anyway.)  When you say this in at a parent-teacher conference or other semi-social occasion it lets you answer the question and move on to the topic at hand.

Dodge

Again, this is not meant to be harsh.  Say something like, “I work in procurement/supply chain management/on computers is still easy to understand, and is more accurate.  It keeps the relationship with your priest honest, but it doesn’t put him to sleep.  If you try this one on, you will come up with a very effective dodge that is entirely accurate but does not put people into comas or confuse them.  (Always gauge your audience and chose the level of detail carefully.)

Be honest

Normally honesty is the best policy.  Sometimes that works here too.  “I do supply chain automation and integration.  But generally if I go into detail I put people to sleep.  It is very exciting to do, but deathly boring to discuss.”  There, I have been honest and tried to explain why I am shutting the door on further conversation.  I have found that this one works well after your Mom or your spouse has just tried to explain what you do, and mangled it to the point that the “lie” and the “dodge” will no longer work.

So what do you do?

I mean, what do you do when asked what you do.  Do you have a pat answer or do you fumble each time trying to maintain conciousness in your listeners?  Or do you have no trouble with this because you don’t have any social engagements that don’t involve your co-workers?  Post your answers to this simple question, “What do you do?”

This was and is a bad thing.  And it can be avoided easily by making sure that you use a passive monitoring system.  By its very nature the state of a passive system has no impact on the system being monitored.

File Based System

In a file based system, the pieces that are being monitored create files to report status to the monitor.  The files sit on the file system where the monitor picks them up and processes them.  In this way, if the monitor develops problems, goes down, or gets behind in processing, the production process stays unaffected. (Unless you fill up the disk with files.  But this too can be managed and monitored, passively.)

By designing the status files so that they contain the relevant timestamps and data, it doesn’t even matter in which order they are picked up and processed by the monitor.  And the health of the monitor can be watched by watching the depth and age of files waiting for processing.

Queue Based System

In a queue based system, the process being monitored writes its status to a queue.  This can be a queue that is part of the system, or residing on the database that the product relies on.  It should not be a queue that is on a non-essential system.  Doing so places the queue as a point of failure for monitoring, or worse, for the product.

Similar to the file system, the monitor goes out and reads from the queue.  This allows the same flexibility for the monitor to get behind without impairing production processes.  And the queue depth and age can be monitored in the same way as the file system to check on the health and activity of the monitor.

Missing points of data

This can be frustrating when trying to plug all of the time stamps for the life cycle of your process onto a map, graph, or other representation.  And when there is only a small amount of traffic on your system, losing even one data point can seem important or even critical.  But including some deductive logic into the monitor, these points can be filled in with the data that exists.

This is the same technique I talked about on my post about Sanjay Shaw and RFID in Supply Chain Managment.  When we gather data points from more locations than needed, and one goes missing, we just gloss it over with an estimated point.  And with a passive system we can insert the real point of data later if it shows up.

We had a problem that sometimes we would not get the final status.  Orders were going out, but the monitor was not getting the last status of the system that delivered them.  We were getting the Order responses.  So we tied in the order response status to the order, and when an order that had no transmission time received a status, we filled in the transmitted time with the Order Response transmission time.  This was not entirely accurate, but stopped hundreds of tickets from being created for investigation where the only problem was the status file.

Insurance

To ensure that your passive system is truly passive, the best test is to turn it off, shut it down, and block access to it and any peices of it that can be turned off and still have the production system running.  This test will show you if you have missed or added something that introduces a new point of failure to your environment.  Anything less will not ensure that the monitor is passive.

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.

When you know what you should be doing, and how you should do it, many tasks become easy.  One of the illustrations of this is shown in my Mapping Excersizes.

Convenient Points of Monitoring

Some systems and technology lend themselves to easy monitoring. These points should be monitored and their data included in the aggregation of monitoring data.  These will very from technology to technology, but these point where data is easy to gather, is well documented, and in a friendly format should be collected and aggregated.

For example, it may not be easy or even possible to monitor when an item in a queue becomes stuck.  But it is possible and may even be easy to monitor how many items are in a queue.  By monitoring the easy point of data, we can find evidence that the queue “may” have stuck items because the number begins to grow beyond a threshold that we have determined.

Helpful Points of Monitoring

Some points are helpful in supporting a system. Having a supportable system should be a requirement, so any point where monitoring would be helpful should be monitored. Only the most extreme obstacles should prevent this monitoring from being in place.

If you have chosen good technologies to be working with, or are lucky enough to have inherited good technologies that have convenient points of monitoring in locations that are helpful to your process, then there should be quite a bit of overlap with the previous group of monitoring points.  Where there is no overlap, implementing a passive monitoring option is a good and recommended strategy.

In the example from the convenient points, the number of items in the queue can become helpful in that it alerts us to a condition that may exist.  When this is combined with other factors, like duration, it can become helpful.  Extending the example so that we are not only checking on the size of the queue, but how long it has been at a certain size, we can know even more information and be in an even better position to alert that a “stuck” condition exists.

Necessary Points of Monitoring

Some points are more than helpful, they are absolutely necessary. These are points where there is a mission criticality to the data. It is beyond mere supportability, but the achievement of the data transfer. Any point that does not have any other points that back it up can fall into this category.

Some times these critical points may only be seen when we expand upon the data that we can see.  If we need to know that our invoice files have been delivered to the accounting application.  But the method of transport is so passive that we can’t tell during transport that it was successful or not.  We may have to build an audit monitor into the system.  We may have to have something on the accounting application side, and the delivery side report as to how many invoice documents were sent and how many received.

Then we can compare these numbers to know if something was lost.  We may even be able to build in a document identification into the  audit so that we will even know which files were lost and only resend those.  Being creative and building a monitors that cover the critical areas of data flow are essential, so even if you have to use primitive methods like file counts, when you put these things together you can achieve a robust and stable environment.

Monitoring the Monitors

One can get carried away in this thinking so that we are monitoring the data. And then we monitor the monitoring system, and monitoring the system that monitors the monitors, and so forth. This strategy creates complexity where simplicity is needed. It is also false positive prone, and thus is hard on the support personnel that need to respond to these alerts.

Instead of having this strategy of cascading points of failure. I recommend redundant points of monitoring. Thus monitoring points support each other. If the first point fails, but the next point in the path completes, then there is no need to alert on the monitoring point that failed. Using this strategy we can utilize monitoring methods that have inherent flaws that cause them to fail regularly, but build them into a reliable, robust, fault tolerant system. An example of this is RFID tags for monitoring the movement of materials.

Applying this strategy makes it possible to cover the critical monitoring needs without having to go to extreems of auditing, or expensive systems changes.

There is a temptation to use this same validation in the production integration. But this would be a mistake. I’m not saying, “Don’t validate.” I highly encourage validation on both standard compliance and required data validation in mapping and integration. But to use the usage specification has a side effect that I witnessed once. (Only once.)

Validating Transactional EDI to Usage Specification

We had an integration requirement once that required that we only allow EDI elements that were in our usage specification. This was outside of our normal process and we all soon learned why.

When we validated EDI files based on the standard, we would error out documents that were corrupted, or in violation of the full EDi specification. (having mangled segments, or invalid UOMs and such.) But this one time, we thought it would be a good idea to also fail documents that had any extra data that we weren’t going to use. So we pulled all of the segments and elements out so that we were just down to what was in our usage specification.

This worked just like we told it to. As when the next file came in that was in bad form with extra trailing delimiters on the line item, it failed. And then the next with an extra segment that we didn’t care about? Well it failed too. As so on.

We soon were buried under failed EDI files that were valid EDI, and did contain the data we needed, but simply had something extra. And we were calling them all exceptions.

At first we added in a few of the common segments that were being sent. This relieved the lion’s share of the errors. But it still cropped up from time to time. Each time we would have failures for this reason we had to explain why. This grew tedious and embarrassing.

Eventually we re-mapped the doc-type using the complete standard in our validation. Magically all of these errors went away, and so did the embarrassing explanations.

Here is the way the process should work, generalized.

1. EDI envelop is validated against EDI standard.
2. EDI document is validated against EDI standard
3. Mission critical values are validated against Usage Specification.
4. File is processed.

What this does is to establish an inherent hierarchy of exceptions.  Transactions that fail on step 1 are all falling because the envelope is corrupt or  in error.  Also, Transactions that fail on step 2 are failing for a general EDI reason.  Both of these steps will have exceptions that can be handled by anyone with EDI knowledge.  Operational and Application rules don’t necessarily need to be known to understand how to handle errors at these levels.

Step 3 and 4 are exactly the opposite.  Errors that happen because of mission critical data that is missing or in error must be handled by someone that knows what the mission critical form is supposed to look like.  And files that pass validation but fail later in processing may need to be corrected and the validation process updated.  Or they may point to an error in the application itself.  In any case, much more knowledge of the whole process is required at these stages.

Take Away

First, by sharing this experience I hope that everyone can appreciate that sometimes requirements make us to funny things.  But I also wanted to share the approach to validation that I have found most helpful.  I have seen implementation that don’t do any EDI or Enveloping validation.  These are just as dangerous and frustrating as my experience.  But now all of the errors are pushed down to step 3 and 4.

I’d also like to invite you to subscribe to my newsletter.  It comes out once a month, starting at the end of this month.  I’ve got some great ideas for it, and think it will be terrific.

Definition:  SKU stands for “Stock keeping Unit” initially used for identifying items that a company keeps in stock so that they can track how many they have and such.  Now also used for services, and for contracts or warranties.

Usage:

The SKU is assigned to each thing.  And it is unique to the company that issues it.  You might think this is the Vendor Catalog Number, but this is not always the case.  The SKU does not just refer to the type of item, say a plate, but also how it is packaged.  So a plate, and a box of plates would have different SKU numbers.  This is one reason that the VCN will not always be the same.  If you order a case, but the vendor is out of cases, but has the same unit quantity of boxes, they may respond and ship the 10 boxes that comprise a case.

Sometimes this is not a great solution.  I had a customer once that ordered a case of tape refills.  The vendor was out of cases, but had the individual refills.  So they shipped 500 tape refills.  The customer then had to inventory and stock the individuals, they were not having a good day.

Sometimes the SKU contains some of the UPC number.  But again these numbers are not the same.  The UPC is about identifying the Unique item type, the SKU is about identifying the stocking unit.

Looking in my handy EDI Standards Reference, I see that on 4010 PO1 line items, the SKU number is qualified by the “SK” qualifier.  If you are using a number you think is  a SKU when you order, but you are qualifying it with a “VC” then you are really using the Vendor Catalog Number.

EDI Example:

PO1*AAA849*100*DP*100.00**SK*123ABC******************~

As you can see, the PO1_06 is “SK”.  This indicates that the PO1_07 is the SKU number.

cXML Example:

<ProductRequest itemNumber=”1”>

<SupplierPartNumber>123ABC</SupplierPartNumber>

<UnitOfMeasure quantity=”1″ unit=”DP”/>

<Quantity>100</Quantity>

</ProductRequest>

In cXML it is less specific.  The SKU number is found in the contents of the “SupplierPartNumber” tag.  This may not always be used for a SKU Number.  However, I don’t know that <stockKeepingUnit> or <SKU> are valid tags in cXML form.

And thus we see why the confusion comes in as to what a SKU is.  Some standards like cXML are loose in their definition of these item identifying numbers and some materials systems as well.  And then others want to know what the SKU is so that they know if a pallet or a envelop are being confirmed on the ship notice.

Rationalizing these systems becomes an important task.  And paying attention to when the type of part number changes can help a supply chain integration alert people in advance of 500 individual tape refills showing up on your table.

Question?

What terms or peices of jargon have you heard people missusing?  Or have you done this yourself?  Let me know in the comments and I may post about some of them as well.

Initial Idea for B2T

First, I need to explain the background of the idea.  I know that not everyone on twitter is, er, human.  Yep, we have “people” that are not real flesh and blood on twitter, tweeting away about what they are doing and why you should visit their site, or buy their product.  Shocking I know, but some of them have quite a large following.  (other twitter bots I think)

So then I thought, (again, in context to the airline example that Jason was blogging about), “Hey, what if I could follow a flight on twitter?  Then I could know when it was due to arrive! When it had landed! And where to meet my buddy in baggage claim!”  (Yes, I think with lots of exclamation marks.)  But I still think this is a cool idea.  Each tweet could have a short statement about the flight status and a link to the airline’s page for people that needed to look up more about it.

Okay, then I had my second thought about how to use this.  You see so far I was still thinking, “customer service by managing the twiterverse”  which is fine, I am a customer expecting good service as well.  But then I put this together with another connection.  “What about Order notifications?”

B2T Expanded to Supply Chain

This is where Jason mentions a supplier monitoring their reputation and customer attitudes by following Southwest’s example.  But I thought, “What if Dell, let me follow my order on twitter? I could know when it was shipped!  When it would arrive!  And even know updates like delays, or arriving early!”  (Again, I think with lots of exclamations.)

Have worked on supply chain systems that sent out many email notifications.  Some users liked these, and some didn’t.  Using a twitter model, a user/customer could follow the orders or processes that were important to them on a case by case basis.  BPM could be followed in the same fashion.  And so forth, just by clicking on the follow like on the checkout confirmation page or equivalent.

What do you think?

What are other ways that you can integrate twitter with e-commerce, B2B, or Supply Chains?  I want to know your ideas.  And also, what do we call this?  (“B2T”, “B2Tweet”, “BtweeB”, etc)

Leo answers a question from Charlie about what makes a software company successful.  Leo responds and explains that it is taking good ideas, and incorporating them in software.  He then goes on to explain that industry leaders like SAP are made by specializing in one line of business.  Companies that only have Enterprise software as one of their business lines will never achieve the same level of expertise.

This is an interesting perspective.  I wonder how someone from IBM or Microsoft would respond.

I also enjoyed the comments by Andrew Mcafee of the Technology and Operations Management Unit at Harvard Business School.  My favourite quote of his from this when responding to Charlie’s assertion that Google had an insurmountable lead over other search engines was.  “I don’t think the people at Google would say there was ever an insurmountable lead.”

Both Andrew and Leo agreed in that the software industry was in flux with a ever present struggle to stay in the lead, or to catch the leaders.  And that keeping people with expertise and knowledge engaged was key to maintaining success.

Thanks to Randy McClure of mcislog for pointing me to this  interview.

This is about a 23 minute video.  It was worth the watch.  Take a look and let me know what other insights you see into SAP and or the supply chain software vending industry from these remarks.

When Defaults Attack

Once upon a time there was a supply chain consultant. (ok, so this was me.) And this supply chain consultant setup and integration between a vendor and a service provider. This hosted integration worked really well for years. Then suddenly we received a delivery at the location of the supply chain consulting office.

Needless to say that our office was not setup to receive the large pallet of materials that were being ordered.

Yes you guessed it. It was an order that had been processed from the service provider but sent to our location as the Ship To destination. Well, we returned it and began a remediation process to find out why our address had been used instead of the correct customer.  In the mean time, the Vendor wanted to charge restocking fees. The Provider wanted their product. And we just wanted to figure out what was going wrong.

Second Order

While we were in these conversations, a second order showed up.  Yep, to our office.  Now we had everyone’s attention.  We walked the order through the process and finally found the error.  Default shipping location in the Vendors system was listing us, the supply chain consultant, as the default location.

The service provider had added a facility to their office.  But it had the same shipping location as the parent organization.  So when they were adding this with the Vendor, they indicated to use the Default Shipping Location.  They assumed that this would be the corporate office.  The Vendor didn’t know this was a problem.  But during the initial setup we didn’t have all of the shipping info, and we used our in the test environment.  Once the went live everything worked great.  No one realized that the vendor had retained our test shipping location.

Resolution

Well, being that we, the supply chain consultants figured out what was wrong, confidence resumed in the integration.  The Vendor removed us from their shipping information, and the Service Provider began to get their shipments for the new facility.  You would think that everyone would be happy.

But there were some shipping and restocking fees that were now on the books.  What a mess.  I think that we eventually spit up these fees and we had to pay a portion of them to clear the books.

Lesson

Find out what happens when things go wrong, before it happens.  Because it will happen.

Manufacturer to Customer

Evan Schuman writing for CBS News relates a Christmas shopping scenario where a store could use RFID to not only tell if merchandise is in the store or in the stock room.  But can be used to tell if the item is lost on the wrong shelf, or in line waiting for checkout.  In the same way, this can give inventory control systems information on order fulfilment.  When an order comes in, is the item in stock?  It the answer is yes we will want to trigger a response to the orderer indication that we can fill their order.  But what if the inventory database has an item listed, that we can’t find.  Using RFID we are able to track where it went in the warehouse, or if it is on a cart, getting placed on another truck or has been pulled by mistake.

Having up to data data on where products are located is not just useful to the sales clerk at Best Buy, but is useful all the way up the supply chain to the manufacturer.  As RFID gains more acceptance and people find real ways to save money and time by implementing it, into their supply chain solutions.

And speaking of RFID acceptance, in a recent article in the RFID Journal they reported that the Air Transport Association is adding an enhancement to their Spec 2000 to include RFID data standards.  This standard from the ATA is not a mandate or an all encompassing specification, but it is a step in the right directions.  As more standards groups begin to include the use of RFID technology in their specifications, the easier it will be to implement cross dock utility, and more timely data will be available for BPM processes and audits.

Benefits of Data

In the end, the supply chain lives on data.  Data on what products are available, where those products are, and how long it will take to get them to the customer or point of purchase.  All of the data points impact the efficiency of the supply chain, and the efficiency impacts the cost.  The more and better data we have the better we can make the supply chain.

RFID is only one way that more data will be collected within a supply chain cycle.  It has the promise to fill in the gaps of missed data opportunities.  What are other ways to pull more data out of the cycle of the supply chain?

• 27% of companies surveyed have CFO’s holding a positive view of procurement’s impact on the bottom line.
• Finance does not believe that Procurement knows how to reduce costs.

As someone from the Procurement side, I have to wonder where these CFO’s have been hiding.  One of the biggest and boldest efforts in supply chain integration during my career have all been aimed at bringing bottom line benefits to the company, and reducing barriers and costs by replacing error ridden, slow, manual processes with accurate, fast, automated ones.  I like to say that Integration Engineers are like Borg, we bring order to chaos.

Bottom Line Impact

It is hard for me to understand how Procurement could not be affecting the bottom line.  Spending on materials and supplies, especially consumables, is always viewed, reviewed and tweaked when budgets are discussed.  So my conclusion is that of the 73% that don’t hold the view that Procurement has a positive impact, hold a view that Procurement has a negative impact.

Ouch.  That is a pretty painful view.  Jason does take a moment to say that this may reflect some what the down turn in the economy of recent months.  But it still hurts.  And as someone who likes to solve problems, I start casting about for a cause.  Why would Finance, and CFO’ think that Procurement was a drain on the bottom line?

Reducing the Cost of Procurement

Things cost money.  So other than buying cheaper things, reducing the cost of items purchased is a difficult to achieve task for procurement to undertake.  So that makes me start to list the areas that cost money in the supply chain, and think about how it can be expressed to reflect savings in the procurement process.

• Systems (the MMIS has a maintenance cost)
• Storage of items received but not in use (like paper for the printer, you have to buy it before you are going to use it)
• Shipping costs (Ordering in advance of need allows for cheaper shipping, as well as ordering from locations closer to the point of delivery)
• Not promoting the cheapest alternative.  (Suppliers may hate to be commoditized, but consumers need to, Procurement is the place for this to happen.)
• Lack of forecasting (if the supply chain is in constant reaction to order requests, and never anticipates needs, trends, etc. then there is waist)

Getting Data in front of the CFO

It is possible that Integration Engineers and other in Procurement are just not letting the CFO in on what they are doing for the company.  There may be institutional barriers, but really the only way to convince CFO’s and people in Finance that Procurement is saving money is to put data in front of them.  This means that it is not enough to implement a system that accurately forecasts material needs, or promotes the least expensive items in supplier catalogues.  Yes we have to do these things, but we need to take the next step and capture the costs saved when this action happens.

How much did we save the company, by replacing the pens ordered with the same pen but at a cheaper price from another vendor?  How much did we save by anticipating an upsurge in printing before the end of the fiscal year, stocking up on paper, thus saving shipping costs?  How much did we save the company by ordering from local supplier locations that both reduce the shipping cost, and reduce the lead time needed to order at a good shipping rate?  We need to be answering these questions, and then repeatedly placing that information in the hands of the CFO.

Are there still Gaps?

Does your organization have sycronization between those in Finance and Procurement?  Does your CFO know how much money the supply chain is saving?  If not, what can you do about it?

But in a quick recap of what you will find in this whitepaper, Nahid Jilovec talks about the historical progress of B2B and some of the triumphs, roadblocks, and challenges that B2B as faced over the years.  But then he goes farther and describes Supply Chain Synchronization as containing three phases; Connection, Communication, and Collaboration.

I admit that during the first few pages it was reviewing things that I learned first hand, but would be a good introduction to someone new to B2B integration.  But then he goes farther and describes some more advanced tactical and strategic ideas that are worth the read.

—-

Do you have some Supply Chain News or Product that should be shared?  Or do you use an integration tool or service that other should know about?  If so, please send me a note with a link or reference to news@theintegrationengineer.com and I will try to blog about it here.

And don’t forget to subscribe to my rss feed.

—-

But today I want to tell you about a company I heard about that has created new efficiencies through integration efforts of a part of business you may have thought was already integrated.  The company is  INTTRA.  And instead of coming up with an untried technology, INTTRA used a combination of existing technologies to do something new.

In and article published by Supply Chain Digest on March 27, 2009, the describes how INTTRA used existing EDI and XML interfaces of Retailers, Manufacturers and Ocean Shippers to bridge the gap and make a manual process automated.

And Harry Sangree, senior vice president of business development and corporate strategy at INTTRA, gave Supply Chain Digest a quote that I think we can all relate to; “What we set out to do is to take a very un-standardized process and make it standardized.”  Is this not at the heart of what we do as Integration Engineers?

They go on to describe another aspect of this business integration that I salute and hope that more companies adopt.  They leverage EDI, XML, email and one line web interfaces.  This approach lowers the bar of the technology needed to benefit from doing business with end through them.

That leads me to one of the other things I find myself ranting about.  Companies that decide that they will only do business with people that do X or Y but not Z.  And so they raise barriers that prevent customers from patronizing their businesses.  I am sure they feel they have good reasons to do this, but sooner or later, someone is going to go after that business, and the one the restrictive company is targeting.  When that happens the restrictive business will be at a financial and market share disadvantage.

So I salute INTTRA, and their efforts to bring the advantages of a more integrated supply chain to ocean shipping companies of all technology levels.

—-

Do you have some Supply Chain News or Product that should be shared?  Or do you use an integration tool or service that other should know about?  If so, please send me a note with a link or reference to news@theintegrationengineer.com and I will try to blog about it here.

And don’t forget to subscribe to my rss feed.

—-

RFID is exciting technology for integration engineers.  All of this data coming in will have to be aggregated and integrated by someone.  Also, one of the focuses of integration is to provide more and better information to people and systems.  With more and better information people, businesses and systems can make better choices and decisions.

This is a good thing.

People talk about privacy issues and consumer protection.  I am sure that debate will continue to rage on long after the keyboard and mouse you are using have RFID tags embedded.  But the focus of this blog is how these technologies can be used for the collection and integration of information.  Implementing RFID technologies provides a hugely beneficial and accurate stream of data.

I don’t think so.  You will now start to handle exceptions.  This means errors.  Most likely you will start to have repeating errors. Someone will have overlooked or misunderstood something, and now every time this thing happens there is an exception.

Because computers won’t stop doing something, just because it isn’t working. Once you set an automated application on its way, it will keep going until you tell it to stop and do something else.  This where the ICI process comes in.  (ICI is pronounced icky)

Integration Continuous Improvement

The ICI process needs a couple of things.  It needs data about the issues.  (frequency, impact, what is done to resolve them, etc)  It also needs a couple of people that meet together to review this data, data around the issues and exceptions, and a regular, repeating time to meet.

Ideally, attendees will include someone from support, best if it is someone that actually solves the problems, not just a manager.  Someone from development, again not a manager, but someone that will be able to code solutions.  Someone from integration, this is us.  And a manager, (yes we do need them), to authorize the work and effort.

The agenda works like this.  First item is a report of solutions put in place since the last meeting.  The developer and integration engineer make this report and the support person can respond to verify that they have seen this resolved.  There will also be the report of errors, that should bear out this report.  Second item is to go over the list of exceptions.  They should have a rating of frequency, difficulty, impact to the customer, and impact on the company.  Based on this, the members of this meeting decide what should be handled and addressed in this ICI cycle.  This work is then assigned to the developer and or integration engineer based on the best way to resolve, and the meeitng concludes.

The first time I encountered this process, we met twice a week.  Within a month, we were meeting once a week.  We kept meeting at that frequency for a long time.  A year at least.  During this time, we improved so many issues that our partners were amazed at how fast we could turn on an issue.  The support group loved us, the account managers loved us.  Heck, everyone loved us.  What was not to love, a small team that had no other purpose but to solve problems.

Of course we also had our regular tasks and there were times that we didn’t have solutions what we could implement in a week.  But when our company acquired a competitor, we were already in place working to solve issues that came up between the two companies.

There are other processes and ways to manage projects.  People who use SCRUM or Agile programming can use that model to address integration issues.  And this can be done with any model, but the purpose here is two fold.  First to reduce the meeting to its essentials.  Second, to give in a frequency and capability to make a diference.

What are other processes that you have used?  What made them good or bad?

Whether we are integrating the data gathered from RFID tracking, or using the techniques in our tracking of data transactions, the benefit is the same; A more robust, and flexible set of data and better issue resolution work flow.

I was particularly impressed with Sanjay’s comments around the challenges of phantom inventory caused by missed reads of RFID tags.  Sanjay mentions that this could be mitigated by using multiple read points.

This is similar to techniques that I have built in the past, but without putting a name to them.  Building a BPM process that expected some of the metric points to be lost, and to be able to fill them in when subsequent point are met allows for a more flexible and rapid system.

This is a bit long, at 42 minutes, but is still interesting.  He spends most of his time using retail based examples, but the concepts are equally applicable to all areas of RFID inventory control, and supply chain managment.

Professor Mansour Javidan, Ph.D talks about supply chain considerations using blue jeans as a case study.  This clip is 3 minutes long.

Professor Javidan gives an amusing illustration of some of the challenges that can occur in supply chain integration.  9 different countries, currencies, cultures to get Blue Jeans to your store.  Each of these will have orders and payments that flow between companies, and across boarders.

This is where having a reliable standard of communication can create greater efficiencies in the supply chain system.   It also illustrates why documenting your supply chain is essential for stability and finding and solving supply chain problems.

So this may not really be news to experienced supply chain integrators, but it is an interesting case study matterial.

EDI is a standard, and having standards in e-commerce or any type of integration, is important in achieving success in your integration efforts.  I found this old video of Bill Gates talking about this very topic, and I decided to share it here.

Bill Gates is speaking in 1998, and mentions the need for standards like EDI in conduction e-commerce.  “Creating those standards…make information move easily…”  “So standards are becoming more important.

Bill and I don’t pal around or anything, and I am not a big fan of Biz Talk, but what he says in this clip supports some of the things that I support here.  Standards make e-commerce communication better.  EDI is a foundation level standard that we should draw from, so understanding what EDI is, becomes important as well.

–

Looking for something else relating to EDI?  Check out the EDI Primer post

–