TGI - ERP Software Solution

Main Menu

Archive for December, 2009

Buying a fully-integrated ERP software suite vs. a best-of-breed solution approach

Friday, December 25th, 2009 by admin

This article will explore the relative advantages of acquiring and implementing a fully-integrated ERP software system rather than buying application software based on a best-of-breed solution approach.

A typical manufacturing or distribution enterprise will need the following types of functionality:

  • Financial management and reporting;
  • Inventory management, purchasing, and order management;
  • E-commerce;
  • Customer relationship management;
  • Manufacturing planning and execution;
  • Warehouse management;
  • Forecasting and planning; and
  • Decision support and business intelligence.

While one could buy subsets of the above list from separate vendors, here are some of the disadvantages to buying this functionality based on a best-of-breed approach:

  • Separate systems with separate infrastructure – separate database instances potentially requiring separate servers.
  • Different look and feel for various applications – users would have to learn different sets of commands and menu structures for different applications.
  • Sharing of data across separate systems – passing of data would generally be done via a batch process.
  • Timeliness of data across the enterprise – even if the data were shared perfectly across the separate systems, there would be time delays between the time data is initially present in one system and when it becomes visible in the other system.
  • Single version of the truth for the entire business – when data is not fully in-sync, there can be differences of opinion as to whose data is correct (i.e., what were the monthly sales figures for customers in a given category or geographical region?).
  • Everyone in the organization works from the same set of information – provides visibility to data from across the organization to make well-informed decisions that impact customers and the organization as a whole.
  • “Least common denominator” for functionality – often an overlooked point in discussion of this topic. There can be some enhanced functionality in one of the functional areas that is the reason the business decided to buy that specific best-of-breed solution in the first place; however, the functionality and data needed from other functional application areas to support and enable that functionality may not be present or easy to access in those other modules, making the new functionality impossible to use.

The following describes the spectrum of integration methods for enterprise-class application software:

  • Fully-integrated system – designed and built from the ground up as an integrated whole all by the same software development organization and team.
  • Separate systems that are owned by the same software vendor – software vendors may have acquired separate systems and developed integration points between these solutions.  In general there would be separate development teams for the various solutions within the given software development organization. The development teams’ primary focus would be on functionality and ease of use enhancements within their specific product lines, not the integration points between various solutions.  There could be a third, totally separate development team for an integration solution from the software vendor.
  • Systems from different organizations that work together – similar to systems that are owned by the same software vendor above, except in this case the separate development organizations focusing on the separate solutions are not owned by the same parent organization.  As you might imagine, this further complicates matters.  One solution provider may elect to change their complete database schema from one software release to another thus disabling any existing integration points. This approach also poses problems for the upgrade process, software vendor roles and responsibilities, and paying maintenance fees to multiple software vendors year after year.
  • One-off integrations by systems integrators – in this case, a systems integrator who is implementing one or more of the software solutions for a given customer may have developed an integration point between two solutions.  In this case, the systems integrator is the only one concerned with the integration – not the development organizations who own the separate software solutions.  This is the most precarious situation of all of the non-fully integrated solutions scenarios.

Core advantages of fully-integrated systems:

  • Data is timely and accurate across the entire enterprise with single points of data entry.
  • Training of personnel in one functional area can translate into other functional areas because the usability aspects of the system as well as core functions (creating new items, querying for data, etc.) will be the same across all areas of the application suite.
  • Single version of the truth – by having one centralized system, data will be the same for the entire enterprise.
  • Integration between functional areas will be the strongest and will be in the best position to enable a company to implement version upgrades as they become available without risking invalidating an integration point between two separate systems.
  • Should be able to take advantage of all functionality in the system without concern about running up against a “least common denominator” situation where functionality in one area of the system may be unusable because corresponding functionality and data may not exist in other functional areas of the business system.

It has been my experience over the years that most organizations who have adopted a best-of-breed approach have not done so based on a strategic decision; rather, they have had a core set of functionality they have decided is the starting point for ERP selection and implementation purposes of a new system.  Rather than focusing on a superset of functionality they will likely ultimately need over time, they may have made a decision to go with an ERP software package that fit the core subset of capabilities very nicely at a price point that was substantially lower than fully-integrated solutions with broader capabilities.

Over time, however, the business outgrows the functionality originally selected and implemented and is now forced to make a decision of whether it wants to keep its existing software and add a bolt-on solution to what it already has or start over and go with a broader, fully-integrated ERP solution.

Organizations are strongly encouraged to step back and ask themselves where they are going strategically and what complete set of functionality they will ultimately need over time so they can buy a fully-integrated software suite that provides this complete set of functionality even if they don’t take advantage of all of its capabilities day one.


ERP System Implementation Critical Success Factor: Proper Planning and Execution of a Data Migration Strategy

Wednesday, December 23rd, 2009 by admin

One of the key elements of any enterprise software implementation is data migration.  Exactly what data is migrated to the new system in what level of detail is a key decision point to be considered during the implementation process.

To be able to make a well-informed decision about what data to migrate, manufacturing and distribution organizations would be well-advised to start with the target of where they want to be with their new system and work backwards.

Assuming there is any reasonable amount of legacy data, the decision to migrate existing data to the new ERP system rather than manually rekey the data becomes obvious.  Data can be categorized into five main buckets:

  • Core base data: including products, customers, prospects, vendors, and associated contacts;
  • Pricing data: customer pricing and vendor pricing;
  • Facilities, manufacturing, and product unit of measure conversion data: including bills of material, formulations, and routings; facilities layouts including zones, locations, and bins; and product-specific unit of measure conversion factors;
  • Historical data: sales history which can be used as an input to generate a forecast and for sales analysis purposes; and
  • Open transactions and beginning balances: including open sales orders, open purchase orders, open sales quotes, open returns, open customer invoices (accounts receivable), open vendor invoices (accounts payable), and general ledger balances by account; these items must tie to corresponding values in the legacy system (i.e., inventory stock status, general ledger trial balance, aged accounts receivable by customer, and aged accounts payable by vendor).

Once the data migration strategy is defined, the next step for the ERP implementation project team is to execute that strategy successfully.  Data migration tends to be an iterative process which can be run three to five times during software implementation.  After each test migration, the data must be analyzed thoroughly to make sure the resulting data in the new system is correct and matches up with proper expectations and comparable data in the legacy system.

For a new ERP system to function properly and provide accurate transactions and business information to be trusted for analysis purposes, the core data, which is the lifeblood of the new system, must be accurate.  The migration of data from legacy systems is a critical success factor for ERP software implementation.


Food Processing Software: Improving Salmonella Analysis Tracking and Reporting

Monday, December 21st, 2009 by Alex Smith

In 2009, the food and beverage industry saw peanuts, pistachios, and prepackaged refrigerated cookie dough recalled and pulled off the shelves at retail stores and warehouses across the country for one reason: salmonella contamination. Many food and beverage businesses were then forced to shut down their operations for good, as their food processing software solution did not give them the ability to record and track raw ingredient lot numbers from suppliers, when those lot numbers were consumed in manufacturing, finished good lot numbers, and the finished good lot numbers that were ultimately shipped to end customers. As a result, businesses were forced to recall EVERYTHING that could have potentially been produced with a contaminated ingredient, a bad situation if you make packaged nuts and trail mixes.

To gain improved salmonella analysis tracking and reporting, food processors and distributors can leverage Enterprise 21’s food ERP software and integrated lot traceability functionality in a number of ways. First, raw ingredients purchased from suppliers can be flagged to be placed on quality hold each time the ingredient arrives into inventory. When the ingredient arrives into inventory, the receiving department would record, either manually or with RF and barcode devices, the ingredient that was received, the quantity that was received, and the lot number(s) for the ingredient received. The ingredient would then be placed in a holding area awaiting quality inspection. It is important to note that the ingredient received would not yet be released into available inventory to be consumed in manufacturing. Following the receipt of the ingredient, a person in the quality control/assurance department would be automatically notified that the ingredient was awaiting his or her inspection. As quality control personnel inspected the product, they could enter inspection values directly into Enterprise 21. Assuming the product is determined to be acceptable, it would then be approved and released into available inventory. If the product does not meet inspection criteria, the product can be rejected, and the quality department can specify a reason code for why the product was rejected.

Secondly, manufactured items can automatically be placed on quality hold each time a given item is produced. Again, as items are produced, they can be placed in a holding area awaiting quality inspection and testing for salmonella. Enterprise 21 would automatically notify the quality control department that a given item has been produced and is awaiting inspection. Quality control personnel can then test the manufactured product, enter inspection data into Enterprise 21, and then approve or disapprove the product to be released into available inventory for customer purchases. Inspection data can also be used to generate a Certificate of Analysis (COA), and this COA can be set to accompany the finished good each time the product is shipped to a customer.

Aside from improving the organization’s quality control inspection process and attaining improved visibility to quality inspection data, food and beverage companies’ customers will be much more comfortable doing business with an organization that can clearly demonstrate that any product shipped to them has been rigorously tested for salmonella contamination prior to shipment. This improvement in customer service ensures that the food manufacturer or distributor is adequately prepared for a product recall should one arise and increases the likelihood of repeat customer purchases given the sophisticated quality control and reporting mechanisms the organization has in place.


Wholesale Distribution Operations: Getting Your Warehouse Operations under Control with Barcodes and Scanning

Tuesday, December 15th, 2009 by admin

Many of the wholesale distributors we meet who are engaging in a wholesale distribution software selection process have a common set of issues.  In general, they are printing pick tickets on paper, handing the print ticket to the next available picker, and telling the picker to go forth and pick.  In doing so, the picker takes the paper pick ticket around the warehouse and writes on the paper to show what has or has not been picked.  Some time later, after the picking process is done – most likely a shift or full day later after the picking has been completed – the paper pick ticket with the picker’s hand-written notes ends up in the possession of an administrator who enters the pick data into the distributor’s existing computer system.

Since there most likely is a substantial time delay between the picking and manual data entry processes, coupled with the fact that the picker’s chicken-scratched notes may be highly illegible, there will likely be errors introduced into the inventory data.  In cases in which the administrator can’t understand what the picker was attempting to convey, the administrator may have a discussion with that picker about their notes.  Again, depending on the time delay between the picking and writing on the pick ticket through this conversation with the administrator attempting to enter the data, inventory accuracy issues can get introduced due to time delays and the possibility that the picker may not even remember what their notes meant.

Even if the manual pick, writing on paper, and manual data entry processes were 100% accurate, they would nonetheless be untimely and inefficient, as there would always be some delay between the time picking was completed and the time data was entered into the system.

Alternatively, for companies using strong wholesale distribution software systems that come with fully-integrated warehouse management functionality like Enterprise 21, when barcodes and scanning are introduced into the process, the system would know the disposition of the picking process immediately at the time a picker was performing those operations.  Furthermore, since the scanning process can also confirm that the item that was intended to be picked was in fact picked correctly, inventory accuracy and customer shipment accuracy will increase.  This should lead to a reduction in the number of customer returns due to mis-shipment of items on an order and an increase in customer satisfaction.

Without accurate and timely inventory data, the ability to leverage that information to have the correct product mix while reducing the wholesale distributor’s overall inventory position are an impossibility.  Companies using Enterprise 21 can achieve these benefits through the introduction of barcodes and scanning throughout the warehouse including the picking process without having to acquire any additional application software.


It’s 3:00 in the afternoon. Do you know where your ERP software support team is?

Friday, December 11th, 2009 by admin

Over the past 6+ years, we’ve heard a lot of questions asked by a lot of different manufacturing and distribution organizations evaluating ERP software systems.  While the great majority of the questions are predictable and heard over and over, there have been a new set of questions that have surfaced recently that are now being asked consistently from prospect-to-prospect.

Do you outsource your customer support services?  Where does your customer support team reside?

These questions have largely arisen in the past six months or so.  Companies can’t afford to spend a substantial amount of time and money to select their preferred ERP software solution followed by another 3-9 months for implementation (depending upon the size of the business) only to realize their new software vendor’s support has been outsourced to a third-party organization who can hold the customer hostage for the long-term use of the new solution.

In many cases when support has been outsourced, those third-party organizations may have elected to move those services offshore to reduce the expense of providing such support.  In these cases, there can be language barriers to effective support, and the offshore support may be unfamiliar with commonly-used manufacturing and distribution industry terminology in the United States and Canada which further compounds the issues.

In TGI’s case, 100% of our implementation and support services for our Enterprise 21 software suite are delivered by full-time TGI employees who work out of our corporate headquarters in Toledo, Ohio.  Enterprise 21 is developed, sold, implemented, and supported exclusively by TGI, and we intend to keep it that way.  That’s what our customers can expect from TGI.


ERP Software Upgrades: Don’t Turn the Upgrade Process into Another ERP Implementation

Tuesday, December 8th, 2009 by Alex Smith

To continue to achieve a return on investment in the years following ERP implementation, manufacturers and distributors should be sure to take advantage of future software enhancements and upgrades to their ERP application. All too often, the organization becomes bogged down in the company’s daily operations and puts software upgrades on the backburner. When this occurs year after year, the software that serves as the information and transactional backbone of the enterprise becomes outdated and puts the organization at a competitive disadvantage, as technology and the mechanisms in which businesses interact with customers is constantly evolving.

When beginning the software upgrade process, TGI customers’ existing production environment of Enterprise 21 is compared to the latest software release, and all prior customer-specific enhancements and configurations are migrated into the newest release of Enterprise 21. From there, the new version of Enterprise 21 is installed on the customer’s hardware, and the customer begins to enact a thorough test plan. This test plan consists of completing a number sample transactions (in a test environment) to ensure that the customer’s requirements are met before beginning to conduct business with the most recent release of Enterprise 21.

Unlike many annual maintenance agreements that charge organizations additional software license fees for future software upgrades, TGI’s annual maintenance plan includes all future updates and upgrades to Enterprise 21 at no additional cost. This philosophy enables TGI customers to continue to realize a return on investment long after their implementation of Enterprise 21 and allows TGI customers to take advantage of the latest software technology for their business without hidden fees or complex financing offers.


TGI’s ERP Insights Blog Is Now Listed in Technorati

Thursday, December 3rd, 2009 by Alex Smith

We’re pleased to announce that our blog has recently been added to Technorati – the first and best respected blog search engine.

And here’s the verification code to prove it: VSGKCGAKVZAC