Monday, June 30, 2008

The inevitable 'Change'

They say that change is the only constant. I’ve heard so many times people exclaim that they need change to happen. But do we really like change? I think, being creatures of habit, we of all hate changes. We are in fact, are scared of change, when our existence depends on it.

Though we loathe at the idea of being governed by habits we humans like any other nature’s creation are a creature of habit. Have you ever noticed that we always will keep our wallets or keys in the same place every day, or take the same route to work or home? Even at work, we have predictable patterns and preferences of how we begin our day. Some like to read the news the first thing, while some would check their mails. Some would rearrange their stuff, while few will head straight for the coffee machine.

Of course, there are things we do change. Like our clothes every day for hygiene purposes or cell phones from time to time. But that’s either that our previous one is mal functioning, or it doesn’t have the features you want or maybe it’s not hip enough. Maybe, if you’re like me, you’ll change it just to break the monotony of using the same device. But these changes are only to our peripheral being or towards our superficial interaction with the society. We all hate to come out of our comfort zone otherwise.

History as we know has often showed us that the ones who don’t change are the ones who face extinction.  And this reason alone drives us to accept the change, whether we like it or not. Like in 2000, when a lot of Software engineers went out of jobs because, they were not equipped well enough to handle the new technologies. Or you pick up a new process; introduce new schemes to stay a step ahead of your competitors.

Yet, there are those who in spite of the changing times survived being what they are. Consider the species like the cockroach and many others from the reptilian family. They adapted to the change but did not go through radical metamorphosis as many others. The key word here and to which I want to emphasize is ‘Adaptation’.

Adaptation by definition is: “to make suitable to requirements or conditions; adjust or modify fittingly”. Ninety nine times to one, a change can be predicted. Rarely did you hit an inflection point without having a hunch or visibility into it. Whether you have enough time to adapt to it then becomes the point in question.  And that’s what we’ll talk about in the next post.

Monday, May 26, 2008

Compiling Java Code without the woes of a classpath

Hello World!
Eclipse and other IDEs’ are a great tool for developing, testing and deploying Java applications and save you the trouble of explicitly writing out commands and statements for compilation, which you'll usually have to type in every time if developing from a simple text editors and command line compilers and interpreters. However, often there has been a need or constraint when you cannot use eclipse for compiling and executing purposes always. Let's say you write a neat piece of code involving classes spread across number of different jars. Now you want to move it to, say, a UNIX environment where it may be required that the class be recompiled and executed manually over command-line for testing. Typically, somebody would've taken the pains to write out an ant script or a build script which would set the class path variable for you, but if the class path is changing quite often due to reasons like (project is still under development) or if the build script is unavailable, it becomes a pain for the developer to type in the name of each and every jar explicitly in his class path every time he needs to compile or execute his code.
However, there is a shortcut to save you from the woes of typing in the class path every time especially when you're in a rush to get things done. You can use the java.ext.dirs argument with your other standard JVM arguments. When used, this option will pick up all the jars under the locations pointed out by this environment, without you have to explicitly mentioning each of the jar file names and location in your class path. Here's an example:
java -Djava.ext.dirs=/usr/j2sdk1.4.2_13/jre/lib:/user/user1/myJars -classpath /user/user1/appln/WEB-INF/classes MyClass
However, this should be used only for development purpose and as a short-cut and not as a standard practice. The right way in the end is to specify all the jars in your class path. The simple reason is that maybe during development you may use a jar and have the backup of the same jar also in one of the pointed locations by java.ext.dirs. As per Java specifications: "The rule of class loading clearly states that once an appropriate class is found no further searching is done. The class which is found (lexically) first is used. This is why you can change the name of two jars in the same directory which contain different versions of same class files and the classes in the jar which is lexically first will be used." So while using java.ext.dirs, you won't be able to control which jar to be picked up by java.
(Special thanks to Diloob for pointing this out and for extensive experimenting with this option.)

Monday, February 25, 2008

Why the noise about System Landscaping?

In examining software maintenance processes for improvement opportunities or for integrating existing systems with newer ones an obvious choice is information flow. Obtaining accurate, up-to-date, and useful information about a system being maintained is a major task. It is also a difficult task because the sources of this information are often limited, inaccessible, or unknown. Clearly this impacts maintenance productivity-simply because of the time it takes to find and use the appropriate information sources-as well as the quality of system changes, which depends on the quality of the system information available. On the surface, maintainers overwhelmingly rely on source code, which is not surprising. However, a deeper analysis show that other sources of information, in particular human sources, some types of CASE support, and lessons learned recorded from previous projects are at least as valuable than source code under some conditions.
Information flow besides information itself, is perhaps the most important aspect of systems design. Not only it is imperical to know how data is stored and processed into information; it is also vital to know as to how the information flows between processes and inter-organizational systems.
During pre-sales and sales cycles, most of the consulting firms earn their bread and butter in analyzing the current systems, information and information flow. This information has a major impact on the deal to be signed as it reflects not only on the current maybe untapped potential of the current environment and its capability and compatibility to integrate with newer systems. The Systems information gathering and data mapping takes considerable time. Since, data mapping is inevitable (every other software will have a different Database design and schemas), systems information gathering reduces the activity time of re-collecting one's own database configuration. Of course, a final verification and validation of native databases is also needed as over the time, they too may get updated or re-configured as part of maintenance activities and change requests.
The System analysis also exposes the available interfaces or in case of incompatibility, the possibilities as to how it can communicate with other systems. Knowing the methods of such an integration also indicates the availability of data. By methods, it can mean the refresh frequency, partitioning of data, whether it is EDI, XML or other procedure.

How to begin with System Analysis?
Instead of tring to answer How to do System Analysis, I rather prefer to answer the question as to how to begin with it lest to save my blog from turning into a book.
Analysis can best begin with the Software side of it; what Softwares are being used, Who are the vendors, what are the operating systems used, what versions of the softwares and OS, etc.
Next comes the physical manifestation and other nuances; what and on how many servers is it running on, Is is partitioned or replicated and whether it is web based or not.
Answers to these questions lead us to the next level where we try to find out the the application aspect of the system. As this level, we try to get a handle on information such as how many business users access the system, how many administrators are present for the system, what are the peak hours for the system, what is the load (CPU and memory utilization)on the system during peak and off-peak hours, the availability of the system (many systems require or recommend a restart over the weekend or month end) and so on.
Going forward, the next step would be to find out about the data itself and the dimensions it is being stored for. For instance, how old and how new is the data, is there data archival available and if historical data can be made available. Also, what are the other dimensions associated with the data apart from time. Data access and authorization and sensitivity of the data itself.
Now, from the vast data that may be available to oneself, the next step and an important one too is to decide how much of the data is required for the new integration or enhancement which is coming through. Without this information, one cannot go forward because here it is decided whther the new solution is feasible or not and also, if the organization can derive any business value from the data (and the lack of it).
Once you know what data to choose and pick from, one has to decide how? Is it through an EDI or is it through XML. Are there batch process running in the background for data update, whether it is real time viz the methods of information flow. What good is data that you cannot access and make use of. Here itself, you'll have to verify as to how many of these existing methods can you reuse and whether you'll need newer interfaces for pulling out the data.

Once all of this is done you're up for the next big tasks namely – the Data interpretation, Data Mapping and transformation rules.

Thursday, February 14, 2008

SCRUM - The New Kid on the block!

What is Scrum?




Scrum is an Agile process that can be used to manage and control complex software and product development using iterative, incremental practices. Scrum has been used from simple projects to changing the way entire enterprises do their business. Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development. Scrum is an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration. It's attributes are:


  • Scrum is an agile process to manage and control development work.

  • Scrum is a wrapper for existing engineering practices.

  • Scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing

  • Scrum is a process that controls the chaos of conflicting interests and needs.

  • Scrum is a way to improve communications and maximize co-operation.

  • Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products.

  • Scrum is a way to maximize productivity.

  • Scrum is scalable from single projects to entire organizations. Scrum has controlled and organized development and implementation for multiple interrelated products and projects with over a thousand developers and implementers.

  • Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.

Scrum naturally focuses an entire organization on building successful products. Without major changes -often within thirty days - teams are building useful, demonstrable product functionality. Scrum can be implemented at the beginning of a project or in the middle of a project or product development effort that is in trouble.


Scrum is a set of interrelated practices and rules that optimize the development environment, reduce organizational overhead, and closely synchronize market requirements with iterative prototyes. Based in modern process control theory, Scrum causes the best possible software to be constructed given the available resources, acceptable quality, and required release dates. Useful product functionality is delivered every thirty days as requirements, architecture, and design emerge, even when using unstable technologies.


XP@Scrum


Scrum has been employed successfully as a management wrapper for Extreme Programming engineering practices. Scrum provides the agile management mechanisms; Extreme Programming provides the integrated engineering practices. An article written by Ken Schwaber and Kane Mar on one implementation is at the Prentice Hall InformIT web site.


Benefits of xP@Scrum include:


The agile management and control mechanisms of Scrum are applicable for any type of project, including business initiatives that consist of multiple, simultaneous software development, business development, re-engineering, marketing, support, and implementation projects.



  • xp@Scrum projects fit within the overall management framework of these initiatives.

  • xP@Scrum projects realize the full benefits of self-organization; teams are iteration (or Sprint) goal directed, rather than story directed.

  • When Extreme Programming projects are wrapped by Scrum, they becomes scalable and can be run simultaneously by non-colocated teams.

  • Scrum implements in a day; Extreme Programming can be gradually implemented within the Scrum framework.

  • xp@Scrum projects benefit from ADM's business value metrics process for measuring and managing initiative ROI.

Wednesday, February 13, 2008

Extreme Programming

What is Extreme Programming?

Extreme Programming (XP) is actually a deliberate and disciplined approach to software development. The methodology is designed to deliver the software your customer needs when it is needed. This methodology also emphasizes team work. Managers, customers, and developers are all part of a team dedicated to delivering quality software. XP improves a software project in four essential ways:

  • Communication
  • Simplicity
  • Feedback
  • Courage

XP programmers communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. With this foundation XP programmers are able to courageously respond to changing requirements and technology.

A Change in the Way We Program

A typical project will spend about twenty times as much on people as on hardware. That means a project spending 2 million dollars on programmers per year will spend about 100 thousand dollars on computer equipment each year. Let's say that we are smart programmers and we find a way to save 20% of the hardware costs by some very clever programming tricks. It will make the source code harder to understand and maintain, but we are saving 20% or 20 thousand dollars per year, a big savings. Now what if instead we wrote our programs such that they were easy to understand and extend. We could expect to save no less than 10% of our people costs. That would come to 200 thousand dollars, a much bigger savings.

Another important issue to customers is bugs. XP emphasizes not just testing, but testing well. Tests are automated and provide a safety net for programmers and customers alike. Tests are created before the code is written, while the code is written, and after the code is written. As bugs are found new tests are added. A safety net of tight mesh is created. Bugs don't get through twice.

Another thing your customers will notice is the attitude XP programmers have towards changing requirements. XP enables us to embrace change. Too often a customer will see a real opportunity for making a system useful after it has been delivered. XP short cuts this by getting customer feed back early while there is still time to change functionality or improve user acceptance.

When should Extreme Programming be used?

Extreme Programming (XP) was created in response to problem domains whose requirements change. Your customers may not have a firm idea of what the system should do. You may have a system whose functionality is expected to change every few months. In many software environments dynamically changing requirements is the only constant. This is when XP will succeed while other methodologies do not.

XP was also set up to address the problems of project risk. The XP practices are set up to mitigate the risk and increase the likelihood of success.

XP is set up for small groups of programmers. Team size between 2 and 12 is perfect, though larger projects of 30 have reported success. Your programmers can be ordinary to use XP. But you can not use XP on a project with a huge staff. We should note that on projects with dynamic requirements or high risk you may find that a small team of XP programmers will be more effective than a large team anyway.

XP requires an extended development team. The XP team includes not only the developers, but the managers and customers as well, all working together elbow to elbow. Asking questions, negotiating scope and schedules, and creating functional tests require more than just the developers be involved in producing the software.

Another requirement is testability. You must be able to create automated unit and functional tests. While some domains will be disqualified by this requirement, you may be surprised how many are not. You do need to apply a little testing ingenuity in some domains. You may need to change your system design to be easier to test.

The last thing on the list is productivity. XP projects unanimously report greater programmer productivity when compared to other projects within the same corporate environment. But this was never a goal of the XP methodology. The real goal has always been to deliver the software that is needed when it is needed.

[Courtesy Extreme Programming Website]

Wednesday, February 6, 2008

Recipe for XML and Web-Services - The Low Carb alternative for EDI

EDI since decades have been the standard for inter-Organizational Information Exchange. Electronic data interchange (EDI) is the transmission, in a standard syntax, of unambiguous information of business or strategic significance between computers of independent organizations. EDI users do not have to change their internal databases. EDI is the common "language" used to get information from one computer system to another. Users must translate this information to or from their own computer systems, but this translation software has to be prepared only once.

EDI has some serious limitations, few of them being:
  1. EDI is expensive, it uses a dedicated communication infrastructure.
  2. The definitions used are far from flexible. For instance, it defines a limited set of protocols and terms with respect to a certain set criterion for specific industries. It does allow business users to add their own custom defined tags.

Becuase of the initial popularity of EDI, most of the financial, logistics and retail businesses depend on it for almost all their information exchange. However, the scenario is slowly changing as the industry leaders, along with standard EDI exposure are also providing an alternative interchange mechanics using Web-Services and XML as the new frontier. XML makes communication easy. It's a great tool for transactions between businesses.


So what is XML?

  • XML is a meta-language. A meta-language is a language that's used to define other languages. You can useXML for instance, to define a language like Web Markup language (WML).
  • XML is a smaller version of Standard Generalized Markup Language(SGML).
  • It's easy to master and that's a major advantage compared to SGML which is a very complex meta-language.


XML: What can it do?

With XML you can :

  • Define data structures.
  • Make these structures platform independent.
  • Process XML defined data automatically.
  • Define your own tags.


However, with XML you cannot define how your data is shown. To show data, you need other techniques Like CSS or XSL along with your XML. XSL (eXtensible Stylesheet Language) is created for this purpose. But the presentation can also be defined with CSS (Cascading Style Sheets).


Now Coming down to Web Services, What are Web Services?

  • Web services are application components
  • Web services communicate using open protocols
  • Web services are self-contained and self-describing
  • Web services can be discovered using UDDI
  • Web services can be used by other applications
  • XML is the basis for Web services


Web Services can convert your applications into Web-applications. By using Web services, your application can publish its function or message to the rest of the world.

Web Services can be used by other applications. With Web services your accounting department's Win 2k servers can connect with your IT supplier's UNIX server.


The basic Web Services platform is XML + HTTP. Web services use XML to code and decode your data and SOAP to transport it.


The Future of Web services - Don't expect too much, too soon.
The Web Services platform is a simple, interoperable, messaging framework. It still misses many important features like security and routing. But, these pieces will come once SOAP becomes more advanced.


Hopefully, Web services can make it much easier for applications to communicate.

Friday, February 1, 2008

Six Steps to a Successful VMI System

Vendor Managed Inventory (VMI) systems came into vogue in the 1990’s as a way to decrease supply chain costs. Unfortunately, inventory crises left many manufacturers greatly disappointed when their new systems did not create the promised return on investment. Robert Schoenthaler, VP of SC solutions at KPMG Consulting Inc. has pointed out, “The lesson learned in supply chain management is that it is a journey, not something that can be solved in a single project. In the 1990s there was an explosion of growth in planning tools. Now the question of ‘how do I execute’ is becoming more important.”


VMI is not a perfect solution to inventory problems. Susan Cohen Kulp, a researcher at Harvard University, recently finished a study on the relationship between VMI systems and higher profits. Not surprisingly, she found that implementation does not always return better results than a traditional supplier relationship. Her study found that information precision and reliability, combined with an effective sharing mechanism, were the key factors in obtaining higher supply chain profits.

So, how do you implement a successful VMI system?

  1. COMMUNICATE expectations of all parties. Customers and suppliers must make the effort to sit down and discuss the goals and objectives of implementing VMI. The importance of this step cannot be overstated. Both parties’ hardware and software requirements must be identified, and an understanding must be reached in terms of how both companies’ systems will communicate. Then a plan for implementation must be mapped, specifically identifying each party’s financial and other responsibilities.
  2. Customer must commit to sharing PRECISE information. Suppliers must have visibility into the customer’s internal sales and inventory information. Without accurate data, ability to quickly meet demand will be impaired.
  3. Suppliers must ensure RELIABLE transmission, receipt, and use of information. To facilitate step 2, the supplier must be able to guarantee that the customer’s trusted information will be communicated, received, and utilized securely and thoroughly to meet the designated needs. Time should be spent during the planning phase discussing information precision and reliability.
  4. Sufficiently TEST systems before going live. As with any new system, testing will uncover any bugs or inefficiencies and can help to avoid future headaches.
  5. Expect implementation to be a PROCESS not a project. Remember that there is no on/off switch. Adjustments will have to be made as demand levels fluctuate, and no system will be perfect 100% of the time.
  6. Plan to spend sufficient TIME AND MONEY to make it work. Most successful VMI systems we’ve read about took 2-2.5 years to put into operation, and cost hundreds of thousands of dollars for IT and training. Spending (or finding) the time to create a comprehensive system can be a challenge.

Inventory Fundamentals

Inventories usually represent between 20 and 60 percent of total assets of a Manufacturing Organization.
Aggregate inventory management works according to their classification (raw material, work in progress, and finished goods) and the function they perform rather than at the individual unit level. It involves:

1. Flow and kinds of inventory needed
2. Supply and demand patterns
3. Functions those inventories perform
4. Objectives of inventory management
5. Costs associated with inventories.

Item inventory management is also managed at the item level. Management rules include:

1. Which individual items are most important?
2. How individual items are to be controlled
3. How much to order at one time
4. When to place an order

Raw Materials are purchased goods received which have not entered the production process, including materials, component parts and subassemblies

Work In Progress (WIP) is raw materials that have entered the manufacturing process and are being worked on

Finished goods are ready to be sold as competed items

Distribution inventories are finished goods located in the distribution system

Maintenance, repair and operational supplies (MRO) are items that are used in production but don’t become part of the final product, including hand tools, spare parts, etc.

Anticipation inventories are built up in anticipation of future demand (i.e. created ahead of Christmas)

Safety stock is to cover unpredictable fluctuations in supply, demand or lead time. It prevents stockouts

Cycle stock Lot-sized inventory are items purchased or manufactured in quantities greater than needed immediately. This is done to take advantage of shipping discounts or minimize setup costs.

Transportation inventories exist due to the time needed to move inventories. They are also called pipeline or movement inventories.
The average amount = (transit time in days) * annual demand / 365

Hedge inventory (usually done with commodities) is done if prices fluctuate and buyers expect prices to rise, so they buy more now

Inventory management objectives include:

1. Maximum customer service (orders shipped on schedule, stockouts)
2. Operating efficiency (build seasonal inventories, larger production runs, but in larger quantities).
Balance this against costs and tied up $$ in assets

Item cost is the price paid for a purchased item (includes direct costs like transportation, customs and insurance) also called landed price. Can also be determined in house including direct material, direct labor and factory overhead

1. Carrying costs include all expenses incurred by the firm due to volume:
2. Capital costs or opportunity cost of $$ tied up in inventory
3. Storage costs including space workers, and equipment
4. Risk costs include obsolescence, damage, theft and deterioration.

Typically 20%-30% of inventory costs are carrying costs

Ordering costs are associated with placing an order either with the factory or a supplier. It does not depend on quantity ordered.

1. Production control costs
2. Setup and teardown costs
3. Lost capacity cost
4. Purchase order costs

Average cost = (fixed cost / number of orders) + variable cost
Stockout costs expensive due to back order costs, lost sales and lost customers
Inventory turns = annual cost of goods sold / average inventory

ABC inventory determines the relative importance of items and then has different levels of controls

‘A’ items – 20% of items account for 80% of dollars
‘B’ items – 30% of items account for 15% of dollars
‘C’ items – 50% of items account for 5% of dollars

To calculate ABC:

1. Determine annual usage
2. Multiple annual usages by cost to get total dollars
3. List items by annual usage
4. Calculate cumulative annual dollar usage and percentages
5. Group ranked items into A, B and C categories

ABC rules are:
1. Have plenty of low-value “C” items (order a years at a time and carry plenty of safety stock)
2. Use money and control effort saved to reduce inventory of high-value items (‘A’ items)

‘A’ items – high priority – tight control and frequent review, expedite when needed
‘B’ items – medium priority – good controls with normal attention and processing
‘C’ items – low priority – use simple controls and order many items

Summary One needs to balance cost of carrying inventory against:

1. Customer service
2. Operating efficiency (longer production runs and fewer setups)
3. Cost of placing orders (decrease with less orders)
4. Transportation and handling costs (smaller orders cost more per item)

Wednesday, January 30, 2008

Looking beyond costs - Strategic Sourcing and Supplier Collaboration

The dynamics of the global market has changed so ever recently that the conventional Supply procurement is almost non-existent. Bulk over-seas and cross-border trading has led to development of newer, more radical strategies. Earlier, Bulk Ordering and Long term agreements meant better Pricing. The picture today if not totally, is different from then. Strategic sourcing Plans are being put in place to cut down on Supply Risks to ensure Supply Continuity. So what do we mean by Supply Risks?

With more organizations moving towards the Lean approach and reduced inventories, the buffer as well as safety stocks maintained by manufacturers have gone down. Also, as per “Just in Time” Strategy - The next batch of supply is only scheduled to arrive when it is needed; not before to avoid Inventory inflation and definitely not late to avoid stock outs. In such a scenario, Delays caused by the supplier in providing the goods on time can be catastrophic and can disrupt the delivery cycle completely.

Another risk associated to Lean manufacturing techniques is the defect ratio and probability in the incoming supply. As per TQM, a particular assembly or manufacturing unit expects to receive parts with zero defects from its preceding unit or supplier. In such a scenario, a defect is only discovered at later stages of Assembly and many times when the product is finished. Manufacturing units and assembly plants can with quite an amount of flexibility can control the Quality checks inter to its organization but has only a limited control over his Vendors.

Also, with Suppliers spread across the globe - there is a significant order lead time associated with supplies. So in case of inaccurate forecasts of demand would lead to an inaccurate forecasting of Supplies which cannot be fulfilled immediately due to Cross border trade restrictions. This would make the manufacturers doing more spot buys at a premium price from the local market during crunch time. This cuts down their profit margins in order to meet customer demands.

Finally, international trade relationships can also be affected with the civil as well as governmental climate of a country. A break of war or civil disruptions in the countries involved in exports or logistics can affect your supply continuity.

Veterans of strategic sourcing more or less agree that more than price, a control over these parameters is more critical. Of course, in spite of the above implications price still seem to be the deciding factor because in the end it's all about making profits. But consider this - a Control over your forecasting and sourcing capabilities with lesser defect turn out in Supply would ensure that you save money if not in cost but in inventory holding costs, lesser defective products and lesser stock outs.

Tuesday, January 29, 2008

Lean Manufacturing: Losing weight through VMI

Lean manufacturing treats work in progress (WIP) as a waste. In fact every imperfection in the system creates the requirement to build work in progress in the system. So the WIP is also known as the mirror of wastes in the system.

On the other hand, most of the brand owners and buyers are moving towards a concept called VMI or vendor managed inventory. Basic principle of VMI is managing inventory by the vendor on the behalf of the buyer. By doing this, customers can focus on their core business of selling. Most of the times buyers are prepared to pay some extra money to the vendors for managing their stocks on their behalf.

Vendor-managed inventory (VMI) systems are a proven technique for improving the efficiency of supply chain operations. VMI is made possible by the implementation of an electronic means of exchanging inventory information between the buyers and sellers of products. These electronic links eliminate many of the built-in delays associated with traditional ordering systems and enable the establishment of collaborative inventory management systems. Experience has shown that improvements in these two areas can result in the elimination of between 20 percent and 30 percent of the previously required supply chain inventory. However, in order to achieve this level of success, it is critical for those companies that have not yet implemented VMI to follow a best practice approach.

Successful VMI programs take advantage of a key supply chain relationship that has been reaffirmed many times over. When trust, cooperation, and business integration among trading partners increase, the level of inventory in the pipeline can go down significantly. Assuming normal business conditions, this can be a direct, inverse relationship that leads to significant improvements to the bottom line for all participants.

VMI veterans, as well as newcomers to the process, will eventually agree on one point: existing VMI processes work fine for dealing with predictable demand, but have significant problems dealing with the less predictable flow that results from sales, promotions, and other special activities. This occurs because the electronic data interchange (EDI) transactions that support VMI lack the flexibility to support true inter-company collaboration in planning for these events.

Benefits for the buying organization:

• Lower costs: Much of the inventory planning will be done by the supplier.
• Less inventory: Better planning leads to lower safety stock levels.
• Better fill rate: Fewer stockouts, resulting in better sales and higher customer satisfaction.

Benefits for the selling organization:

• Sticky customers: The implementation of VMI processes leads to a tighter relationship with buying organizations, making them less likely to switch to a competitor.
• Reduced inventory: Increased supply chain visibility enables better inventory planning.
• Reduced cost: VMI enables tighter integration of vendor needs and production planning, resulting in more stable production and fewer "rush" orders.

The most common process used to support VMI is EDI-based exchange of two X12 transaction sets: the “852 Product Activity Transaction” and the “855 Purchase Order Acknowledgement”.

Electronic Data Interchange (EDI)
EDI is an inter-company, application-to-application communication of data in standard format for business transactions. Electronic Data Interchange (EDI) is a set of standards for structuring information that is to be electronically exchanged between and within businesses, organizations, government entities and other groups. The standards describe structures that emulate documents, for example purchase orders to automate purchasing. The term EDI is also used to refer to the implementation and operation of systems and processes for creating, transmitting, and receiving EDI documents.

Electronic Data Interchange (EDI) can be formally defined as 'The transfer of structured data, by agreed message standards, from one computer system to another without human intervention'. Most other definitions used are variations on this theme.

ASC X12 (also known as ANSI ASC X12) is the official designation of the U.S. national standards body for the development and maintenance of Electronic Data Interchange (EDI) standards. The group was founded in 1979, and is an accredited standards committee under the American National Standards Institute (ANSI). The acronym stands for "American National Standards Institute Accredited Standards Committee X12", with the designation of X12 being a sequential designator assigned by ANSI at the time of accreditation with no other significance.

ASC X12 has sponsored more than 315 X12-based EDI standards and a growing collection of X12 XML schemas for health care, insurance, government, transportation, finance, and many other industries. ASC X12's membership includes 3,000+ standards experts representing over 350 companies from multiple business domains.

852 Product Activity Transaction
A warehouse distributor or retailer who advises a trading partner of inventory, sales, and other product activity information can use the Product Activity Data Transaction (852) set. Product activity data enables a trading partner to plan and ship, or propose inventory replenishment quantities, for distribution centers, warehouses, or retail outlets. Each pair of trading partners should determine the frequency of data transmission. Data should be transmitted at least once per planned replenishment cycle, although more frequent data transmission is worthwhile. The balance of data transmission and processing costs must be balanced with the benefit of more frequent data.
Similarly, trading partners should determine whether all part numbers should be included in each transmission or only those with activity. For instance, a monthly transmission could include on-hand balances for each product while weekly transmissions would include only those products having sales, returns, or inventory adjustment activity. The transaction set is constructed to allow up to 200 reporting locations to be included in each transmission, and up to 999,999 products. This guideline recommends minimizing the amount of data being transmitted to satisfy requirements for trading partner automatic replenishment of inventories. After the trading partner processes the data, the receiver of this transaction set would send a purchase order acknowledgment to the sender. The purchase order acknowledgment would include purchase order numbers being assigned for each reporting location, the date the order was processed, and the items and quantities being on order.

855 Purchase Order Acknowledgement
The electronic purchase order acknowledgement will typically contain exception-only information provided by the supplier about the customer’s purchase order, such as:

• A part ordered has been superseded, and the superseding part is being shipped;
• A part ordered is obsolete, and cannot be provided;
• A quantity ordered is being changed to match minimum or multiple quantities offered by the supplier; or,
• A part offered will be shipped from a special distribution point, and won’t be included with the regular shipment.

This information referenced on the purchase order acknowledgment is currently included on the shipment packing slip. However, when the distributor does not know the information until the shipment is received, confusion occurs during the receiving function. Because the supplier knows of these exceptions when the customer’s order is first processed, the exceptions can be electronically transmitted to the customer in advance of shipment receipt. In that way exceptions are greatly reduced:

• Unexpected, superseding parts received are known in advance;
• Other actions can be promptly taken to find obsolete parts;
• Unexpected quantities are known in advance; and,
• Multiple shipment receipts can be planned.

The distributor would likely integrate the purchase order acknowledgment into his purchasing system, and allow an audit modification of the original purchase order. Therefore, receiving operations continue unchanged while exceptions decrease dramatically.

Process:

On a daily basis, the retailer organization calculates sales and inventory data for each item and forwards this information to the appropriate suppliers using the 852 Product Activity Data transaction. Upcoming promotional plans can also be forwarded within these electronic documents. Software on the manufacturer’s end calculates the level of retailer inventory required to support the current level of sales activity and planned promotions. The manufacturer’s system creates the corresponding purchase order and sends an 855 Purchase Order Acknowledgment back to the retailer. The retailer feeds this information into its system as if it were an internally generated purchase order. The entire cycle can take less than one day, compared to four to six days under the old system.

Because this electronic exchange of product information enables the entire process to move much faster than the old paper-based system it replaced, both the retailer and the manufacturer can achieve significant cost savings due to reduced supply chain inventory levels. The retailer needs less safety stock inventory in its distribution center(s), and the manufacturer is able to implement better production scheduling to match real demand and, therefore, carry fewer inventories in its distribution center(s).

The retailer also benefits from improved customer service: experience has shown that manufacturers can frequently forecast sales of their products better than the retailer can since the manufacturer has access to sales activities of the same products from multiple retailers and gets a better picture of actual demand and promotional results across a much broader marketplace.

VMI can directly impact the bottom line by reducing inventory levels, but it also improves top-line revenue by elimination of stockouts, which cause customer dissatisfaction in addition to the lost sales opportunity. Helping to drive the top line is often more exciting to top management than cost reduction and assists in making the supply chain function a more equal partner in running the business.

Inventory in finish goods form is harder to manage. But when the inventory is managed by vendors they can manage it in other forms for an example as raw materials and as semi finish goods. Vendors will happy to have a VMI type of orders than a normal order. But the reality is in whatever form inventory is a waste. So in the ideal scenario vendors would manufacture goods as and when the buyer wants it and then will dispatch to the vendor instead of pulling goods from the inventory and sending it to the buyer.

Although VMI or vendor managed inventory have the term "managing the inventory" it does not necessarily mean that vendor should have a huge inventory. A lean manufacturer would be able to get the best advantage of this concept than a traditional manufacturer if managed carefully. Having a front end working in VMI model and the back end of the business working with lean manufacturing makes a powerful combination. Vendors order goods when they want it in small frequent batches. Manufacturers do their manufacturing when they receive the order in small batches with a very short lead-time. Isn’t this the ultimate lean manufacturing system?

Monday, January 28, 2008

Information Technology and Indian Apparel Retail

India being one of the new emerging economies has opened it's gateway to a host of new products and brands. Many businesses are now targeting the Indian population as their new market and potential customers. The retail segment is booming and the Indian consumer is now looking beyond the store at the corner of its street. With global as well as Domestic retailers compete to capture the Indian market, Strategies are being evolved and deployed tailored for the Indian market. Yet however, for numerous reasons, the domestic retailers fail to comprehend the need of Information Technology (IT) in their supply chain whereas, global retailers are spending a considerable amount of their revenues in deploying more IT based solutions. Indian retailers are more focused in increasing their sales by providing a competitive price compared to their counterparts, where the global retail mind is strongly focused on making their business more agile. In fact, the focus of the industries is so impressive that they are the new preferred customers of many Supply Chain solution providers.

So what keeps us as Indian retailers from investing into IT solutions? Stating the obvious - The investment involved. Any quality service provider has premium rates. The lesser ones in the category aren't reliable enough to deliver complex solutions usually associated with Supply Chain Management (SCM). Licenses of SCM engines don't come cheap and that's not all. There's a non-trivial cost involved such as the consulting, Deployment and maintenance of complex solutions.

Quite of the failure of IT in the domestic market can be attributed to the way the economy is driven locally. Organizations have yet to evolve to a system where the demand is first created and then fulfilled (pull Based System). The biggest names in domestic retailers are still buying the grey Stocks in order to reduce the buy price because for them their only USP being a competitive price. This way they end up competing among themselves. Global retailers on the other hand are striving towards adding more value to their supply chain and making their business more agile. IT solutions like Decision Support Systems (DSS), Enterprise Resource Planning (ERP) and e-commerce gives higher visibility into their supply chain. They get better managed inventories, more accurate demand forecasting and fulfillment. They work towards optimizing retail cycle and reducing cycle time. They continue to provide premium content to the customers and survive the competition from the Domestic market.

Another big one is the executive and the middle management level mental roadblock and lack of faith in IT. This mentality can also be attributed to the lack of awareness and knowledge of them in the IT itself. In case of Developed Economies, the IT and automation is omnipresent to the level that people even don't notice them around. Compared to societies where people order food online, we are in a phase where many of us still rely on Cheques and pass books when facilities like ATMs are available to us. Even though organizations in India have accepted automation and IT, it is poorly implemented and loosely coupled. Many Formidable manufacturers and Retailers have ERP available and yet they use it for purposes which probably can be taken care by some neatly designed spreadsheets and simple databases. CRM solutions are being implemented but then are not vertically integrated. Hardly Indian retails have an e-commerce website.

Like there's a dawn to every night, both the retailers as well as solution providers are waking up to the new realization. SCM Product companies are working towards a better pricing model for Indian market like Subscription based and On-Demand Solutions. Few of the retailers already have started looking in this direction and though with difficulty, started shelling out hard earned bucks. Maybe, this is the first sign of the changing winds.