We have been discussing master data over the last few weeks and our belief that there are ways to improve the access to the specific data for a specific customer.

In the retail industry, we (the industry in standards efforts) made a very difficult improvement to the use of standardized codes and numbers.  People not familiar with the specifics of retail data will still recognize the bar codes that are on products in supermarkets, mass merchants, category killers and department stores – basically everywhere.  Getting order and integrity to the use of standardized codes has been a major success story in business history.

Other industries believe that they do not have the need for such specific standardized product identification.  Although, last week when I was trying to find a particular type of Matt board to frame some of my photography, I wish that everyone did identify their products this well.  It took quite a while to find “very white” board that matched what I was looking for – even though I know it was a specific model number from a specific manufacturer.

And where do I find an eSATA interface card for my Power Mac G5 that is a few years old – what is the specific card that works for the specific drive that I want to attach to my computer?  The clerks at the stores that I have been too, have just looked at me and said – “What?”

Regardless of whether standardized codes are used for product identification, we believe that data quality – and customer satisfaction - can be improved if the knowledge about the use of the product is available and machine readable so that the products can be searched and the proper attributes delivered to the customer.  Of course machine readable data is also searchable be the staff.  I knew the card that I wanted had not shipped as yet; I was just having fun with the store staff of the retailer.  The point is he did not have access to the knowledge.  If he did, I would buy it form them when available – as it is I will buy it on-line.

Fortunately, there is significant progress being made in the storage and retrieval of knowledge about the products that are in the supply chain.  This knowledge, properly stored and retrieved can eliminate much if not - all of the - quality problem that comes up with trying to use data from multiple systems fit it into customers requests for information.

In my Matt board example, the distributor that answered my text based inquiries first got the order – not a big deal it was about $300 – but the last time I looked getting a sale is better than losing a sale.  For that industry – one that is “artistic” in nature - human (even text email messaging) interaction is essential.  I needed to ask questions of the “knowledge plane” of those companies – the customer service department.  In the world of data provisioning, staging and alignment – that request is automated and needs to be packages into to standardized or defined messages.

The technology for the storage of this knowledge about the data is in development and use is under discussion.  We believe that it is time to start looking at how a knowledge plane above the relation and distributed data about master data can solve the problem of “dirty data” or incomplete data in the data synchronization efforts in the b2b supply chain.

We like to think of this “knowledge plane” as the semantic plane – and it sits on top of disparate data sources – like price information, ingredient or bill of materials, image, warranty, detailed specifications and the like.





The knowledge about the items is stored in that plane.  When a price request by a customer is submitted the information for that customer is created based on knowledge about the programs in place, contracts for that customer, supply of the item, transportation surcharges and anything else specific to the supply chain in use.

When an image is requested the image for the particular version of the product that the customer needs and the use case for the image and the dimension data is fulfilled – so the plan-o-gram image (the small images used for in-store “maps” of the shelf in a Supermarket or Mass Merchant) – represents the product currently being shipped to the customer – not last years image and size data – or next years but the current one.  Of course the customer should be able to request either.  Also, if a high resolution EPS (Encapsulated Postscript File) is needed for an ad, it needs to be the one for the product that will be found in the supply chain when the ad is running.

Other examples, I am sure come to mind, but I believe that the point is clear. All of this data is in different systems – and usually in different locations.  There are different security mechanisms in place for much of the data.  But the knowledge of what is the authentic source of information for a particular request is probably distributed around the enterprise in the heads of associates.  The semantic plane will store that knowledge and to the degree possible answer the request accurately.  When not possible there are other Web 2.0 social networking tools that can alert the person that has to figure out the request and put together the data construct for the customer request.  One of these tools – Twitter was discussed on Monday in our Blog.

We believe that concepts like the Semantic Plane and the use of social networking tools inside of the Enterprise can bring about a significant improvement in the quality and accuracy of the data being offered to customers.  For more information about this approach please contact us at sales@dharacg.com.

Fred Geiger
www.dharacg.com

Posted by Sastry at 3/5/2008 9:41 AM | Add Comment

_{-- Delivered by Feed43 service}

]]> 00a016f00e44533b4271eaeeee6b7f13 Social Networks

As part of our CIO focus at Dhara, we like to keep current on trends in the IT Industry.  Last year when we began to look at Web 2.0, it was apparent that some of the mash-up techniques had legs inside of the enterprise.  In discussion with our stakeholders and contacts in large US companies, it was also apparent that CIO’s were trying to get their hands around the social networking component of  “Web 2.0”.

Last week I saw a survey one the plans to deploy social networks inside of the enterprise, and it is apparent that the vast majority of CIO’s are open to this, and that about the same number are concerned about security implications – as soon as I verify that we can link to this survey, I will edit this post and include the link.

So, many believe that it is time for companies to look at the use of the social networking components of the Web 2.0 technology base. We assume that IT people want to determine how they can be used inside of the enterprise to decrease the need for physical travel and increase the contribution of team members to the finished product – which is always important in any systems development lifecycle.

This week we are looking at one of those tools – and the potential impact to the CIO’s office.  The tool is Twitter (http://www.twitter.com) which is a tool that allows messages to be routed to a cell phone or sms client.  While the product’s stated intention is to keep track of people using a “publish – subscribe” model, the ramifications for business use are great – which means that your users and probably some of your staff has been using it already.

Basically a user searches for his or her buddies and subscribes to information that they post and these subscriptions can be filtered.  This type of model ahs been used for business applications like data synchronization for close to ten years now.  But the use of it using chat clients and cell phones and allowing individual users to set it up should be looked at from a corporate risk perspective if it has not already been done.  How many messages are being sent to your cell phones now?  And at what cost? Do you have a policy regarding its use?

An interesting application though offers potential for use as an alerting mechanism.  On Tech TV last week, a Twitter user talked about the use of Twitter to route messages to him from his plant telling him that it needed watered – and the plant was even polite enough to thank him for doing so.  So putting a monitoring mechanism on his plat that is Internet enabled and creating alerts is a cool idea – one that had me thinking about monitoring my home and sending me messages to that I could subscribe to in a variety of form factors.  It also made me remember how many different alerting mechanisms we had in the last environment that I had to manage and how much the infrastructure cost. 

At Dhara, we are looking at the infrastructure used by Twitter and will report back on how we are able to apply this technology safely in our environment as we go forward.  In the meantime, if you would like to discuss projects like these, please feel free to email us at sales@dharacg.com

Fred Geiger
www.dharacg.com style="font-family: Verdana;">

Posted by Sastry at 3/3/2008 5:13 PM | Add Comment

_{-- Delivered by Feed43 service}

]]> e19918c7b9aad207d8e7189e63cf3831 Sourcing Pitfalls

Last week in my Blog entry on sourcing, I gave a success story.  This week I want to focus on some of the pitfalls of development off shore.  No, this is not a failure story, but it expands on the explanation of some of the areas that are barriers that have to be overcome or avoided.

It is tempting to focus on the cost of development and look at the hourly wage of the resource.  When you compare twenty dollars and hour or less to numbers four to five times that number, it is easy to set expectations for savings that are unrealistic.  One of the consistent temptations for technologists is what Chairman Alan Greenspan of the Federal Reserve referred to as “irrational exuberance”.  The times that I have gotten into trouble in my career are the times that I believed my own hype and oversold the benefits of a proposed project or direction.  Kind of like the economy did back at the turn of this century when the bubble burst.

In many companies in America, change happens at a very fast pace.  We, in America, pride ourselves on our flexibility.  I remember my frustration thirty years ago trying to mange development projects in the then common “waterfall” methodology.  For those of you that learned about the sixties and seventies in textbooks – or on the History Channel, the waterfall methodology was one in which projects progressed sequentially until they finished by “falling over the waterfall”.  It was aptly named – often times it was like going over the falls in a barrel because the requirements changed over the lifecycle of the project.  And they were discovered at implementation. It turns out that the requirements that were signed off on in the first phase of the project – the requirements phase – changed in the months (or years) that it took to get the product complete and installed.

Today, it is often easier to develop systems using a variety of iterative construction techniques – but these are best applied when the project team is very close to the users.  In the fast pace change of America, it is common for systems to be changed significantly during the development effort – especially if the methodology supports rapid prototyping and extensive user reviews.

Implementing these techniques with facilities that are half way around the world and in which language and culture are different can produce business systems that do not meet the real user need – because that need was lost in nuance.  We in America understand our culture – we understand that the newspaper headline of “Bucs bomb birds” during football season indicates a good day for the Tampa Bay Buccaneers  (aka  “Bucs”) and a bad day for Philadelphia Eagles (aka “Birds”). Of course if the World Series was going on and however unlikely it would seem right now, the Pittsburgh Pirates beat the Baltimore Orioles – what was the real story – football – or baseball?  You have to understand the nuance of the comment and the context of it.

We in America, understand the nuance of the way that we communicate, people not familiar with our culture do not. They do not.  Even here in the states, it is not uncommon for a new analyst or programmer to not understand jargon – I remember a new analyst in my own career in technology who did not understand what a PO (purchase Order) was and was afraid to ask.  Here the answer was provided after the meeting and the requirements were captured.  How does that happen off shore?

Well, it can happen, but it has to be planned for.  We used a daily call to make sure that all questions are answered. Often times that meant that we had to create and answer the question.  In America we are “in your face” people.  Other cultures want to save face, and not look foolish.  I learned that yes does not mean yes.  In some cultures it means that the person understands – not that they agree.  In other cultures – it can mean that they do not want to argue – they might not even understand.  For an excellent primer on cultural differences the book Kiss Bow or Shake Hands by Terri Morrison and Wayne A. Conaway helped me greatly.

So in addition to making sure that we were clear in requirements, we avoided areas that were fuzzy.  We created those components in the states where people were closer and could interact with the users of the products or services.

In order to put together a project team to support this type of project we found that we needed two teams in Asia of five to ten people, a full time manger in the states who worked across the two Asia teams and provided direction and issue resolution and a team in the States to define requirements, and test criteria as well as perform the integration testing and implementation. I would recommend that your on-shore team also fully understand the technology that has been developed so that critical issues can be fixed – especially during Asia holidays and weekends that do not map to our own.  When a problem arises – make sure you have an answer to “who are ya goin call?”

All of this points to an interesting realization – if you do not have a large project – the cost benefit of going off-shore is not really realizable – perhaps savings can be had by engaging a company that provides local support in an affordable fashion.  Next week we will look more closely at trends in this area.

Fred Geiger
 www.dharacg.com

Posted by Sastry at 2/29/2008 9:00 AM | Add Comment

_{-- Delivered by Feed43 service}

]]> 3fc8f85cdde329a4e2192db52eea3c50 Master Data Lifecycle

One of the challenges in preparing master data requests that are issues by customers is the notion of the “lifecycle” of the product sold to the customer.  This is particularly true in mass merchant and supermarket retail where an item is sold in the stores to consumers and is always “stocked” in the same section of the store, or at least it is supposed to be in stock when you go to look for it.  Out of stock conditions drive everyone in the supply chain crazy.

Products change from time to time;  for example, formulas change.  High fructose corn syrup used to be “good, but now many people believe it is bad;  out with the sugar and in with the corn syrup;  and out with the corn syrup, in with the next new thing.  So, when master data includes ingredients and images, the information for the product in the stores and the retail distribution system is different from the information for the products in the supplier’s warehouse.  Thus, the information about new shipments is different from the information about old shipments, which causes some orders sent to or from multiple distribution systems to change.

In other cases, the country of origin (also with master data, often times) changes which can cause differences in the product formula, as with fabric content, for example, in fashion items.  So as an item’s sourcing moves from Mexico to China, or from Ohio to China, there are differences in master data.

Regardless of where the” knowledge” about this is stored, someone, somewhere, in the organization of the supplier “knows” when this is happening.  Unfortunately, “systems” in place, built perhaps when China was never considered for sourcing items, do not have this knowledge.  So when a customer asks for “synchronized” data, or when a customer makes an information request for a radio frequency identification (RFID) tag, sourcing the correct information is often times problematic.

At Dhara, we have been working in this space (master data staging) for ten years, and as we have reported in this blog, we believe that mashing up the various sources of data for the fulfillment of the information requests is essential.  We believe that discovering and storing knowledge about the requested data is an essential step in the proper fulfillment of the information request.

When we talk about knowledge, what are we talking about?  Well, some examples might help.  What warehouse is used for each customer request?  What warehouse is used for backfilling requests that cannot be handled by the prime warehouse?  Who sources each warehouse?  When a sourcing is changing, how is it staged and whose orders are affected?  What is the schedule for the change of formula in the product?  What lots are affected, and who is getting those lots?  Does an order for a customer span lots?

This is not just about the fulfillment of information about business-to-business requests.  This information should be available for business to consumer requests.  My spouse and I have used the Internet for much of our shopping for some time now.  In buying things that are fashionable, it would be very helpful for us to know that a pair of jeans that one of us bought is being sourced in the same place the next time we go to buy them. There seems to be something “unstandard” about sizes between different sources of products.  The consumer might not know to ask, but she realizes that there is a difference when the next pair of the “same” jeans does not fit as well as the last pair.  In this case, the knowledge of where the last order was sourced from, and information about the fulfillment from the same source for the next one, is really needed by the operating system’s supplier–the consumer should not have to know that.

There is new technology for storing this knowledge inside of computer systems, and next week I plan to look at the use of a semantic plane inside of the supplier’s systems, which processes source information requests for master data.

Fred Geiger
www.dharacg.com

Posted by Sastry at 2/27/2008 5:43 PM | Add Comment

_{-- Delivered by Feed43 service}

]]>