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.

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 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.

—-

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.