A Spreadsheet Is Not A Database

There are some serious misconceptions about how to best use certain types of software. It’s rather common now to see CEOs, financial wizards and others use presentation software as simply a place for their notes. Too often, what’s on the screen could have been given to the audience members to read instead of the presentation software being used as it was intended; To visually augment what is being said. All those bullet points on all those screens … it’s just not right.

Likewise, many office workers and managers look at a spreadsheet program as a database instead of the accounting tool it was meant as. The first spreadsheet program was called VisiCalc and, as it’s name implies, its intent was for calculating visually. It was never intended to simply hold data. However, that’s what many people use it for. They then wonder later why they can’t get it to do what’s necessary once growth occurs and other features are needed.

A database can not only store data in table structures, those structures can also be made “relational”. An table containing orders might only contain the order number and the date it was initiated. Another table might provide customer names and addresses, simply because each customer might have multiple orders. Another table might then contain order details, or lists of the items within the orders listed in the Orders table. And finally, a view might tie all these together so each individual order can be viewed as a single record.

A spreadsheet can’t do that, because a spreadsheet isn’t a database.

As in carpentry or auto work, computers are also best operated by using the right tool for the job. Maybe it’s time to step away from the spreadsheet.

Custom Terminology in Manufacturing Software

“We need to change everywhere it says ‘Product’ to ‘Asset’.”

“They want to see the word ‘Scrap’ instead of ‘Waste’.”

“Under Locations … let’s see … they store assets in vans and warehouses, but since the warehouses have shelves and bins and the vans don’t, and the vans aren’t physically attached to a given warehouse, the warehouses and vans have to be set up differently …”

These are real conversations which happened in the past week or so while developing custom-tailored manufacturing software for certain clients. That’s how detailed things can get. Virtually everything is flexible, anything can be changed, and if your Product is an Asset, so be it.

It’s a given that any company, particularly those with a long history, have developed their own internal culture. With that culture, an overall terminology has also developed within the overall workflows of the company. If canned software is then introduced as a management or reporting tool within that culture, how effective can that software possibly be if the software causes terminology, and ultimately cultural, changes?

Custom-tailored software is by far more appropriate as the software is built to fit within the already-existing culture and its built-in terminology. And certainly, workers and managers are going to be more willing to use software which doesn’t force them to make changes to their workflows in any way.

Besides, ‘Scrap’ sounds much better than ‘Waste’ anyway.

Custom-Tailored Scheduling Software

When moving from sticky notes on a hunk of painted plywood to automated scheduling software it’s easy to get caught up in all the possible features of a canned, out-of-the-box, off-the shelf package that seems to do everything you need and then some. It appears to have everything you need, it definitely appears to have everything your manager wants it to have, and there are a ton of things in there you might be able to take advantage of in the near or distant future.

Not so fast …

Think about that for a moment. Why are you considering paying for features you might use in the future? What if you don’t use them? A better question should be, what about when you don’t use those features at all?

Take a good look at the office software you have; The word processor, the spreadsheet generator, the presentation package your boss uses for every meeting and puts pretty picture in with his notes. Have you ever even looked at that database thingy that came with it? What about the templates and macros in the stuff you do use? Do you even spellcheck??

Now take another look at that canned, out-of-the-box, off-the shelf scheduling package that seems to do everything you need and then some. How much of it is going to end up a complete and total waste of hard drive space?

Custom-tailored scheduling software, built specifically for your company’s needs and culture, is much easier to use than a canned system simply because it’s built the way you and your company needs it to be built.

I once knew a blind couple who designed their own house. The architect set them in front of a pegboard with some pieces of wood dowel. Each gap between holes in the pegboard was meant as a single foot of distance. The couple layed out the pegs to create their floorplan, which the architect glued together for them. He then developed the blueprints from the pegboard, which the blind couple continued to study with their fingerprints. When the couple walked into their new house for the first time, they knew exactly where everything was.

That’s what custom-tailored scheduling software can do for you.

Module-Based Thin Client ERP Software

We’ve already talked about thin-client software and how it can be utilized anywhere within a facility on any computer with an internet browser installed. When developing software for this purpose the need for a module-based system becomes apparent when the actual requirements are discussed. This is due to the need for some functionality at first with the ability to add other functionality later.

Let’s say a facility is looking for a Scheduling system. With a thick-client software system built from the ground up, development of the software could easily take a year or more. The database has to be designed, relationships between tables and views need to be anticipated, and then the development of the scheduling portion itself can be begun. Once this is put into place, debugging needs to occur at a beta level. Test runs are executed and any issues fixed. Only after a lot of debugging has been accomplished can the software actually be installed and used, some months or even years down the road.

At that point, if more functionality is needed the entire process starts all over again. And then there are updates to the operating system, security patches, and constant updates to the software itself.

A module-based framework is much simpler from a development aspect. The framework and its modules are already proven and in some cases might be appropriate on their own for a given situation. Customization of the modules for a given situation, which is quite often more appropriate, can take a matter of weeks to accomplish. And any additional functionality can be added through the addition and customization of another module or two later on down the road.

Companies such as Tuppas Software specialize in these types of custom-tailored module-based software systems. This is the kind of company to seek out for manufacturing software solutions.

Just In Time (JIT) Inventory

In the book “Quest For The Dawn”, the written history of Toyota, the story is told of how Toyota Motor Corporation founder Eiji Toyoda and Toyota engineer Taiichi Ohno baffled manufacturing representatives and factory architects at the time with the blueprints for their first factory. There were no warehousing rooms for parts inventory anywhere in the plant. When asked where the parts would be stored, the two replied that the parts would be at the correct place in the production line at the right time and no sooner.

This is the simple theory behind Just In Time (JIT) Inventory.

In the Toyota Production System, a parts inventory is considered to be waste, not only in the cost of an inventory that just sits there but also in the overhead necessary to manage the warehousing rooms. JIT Inventory is the result of this philosophy.

The end result of a JIT Inventory system is that every product a plant manufactures becomes a special order. The product is ordered, and the build of that product is constructed in reverse to develop what’s needed to ensure the end product is built correctly. Arrangements are made to ensure the necessary parts are where they need to be in the production line at exactly the right moment as the product is built. Overhead pull lines along the production line allow any worker to stop the line if a part isn’t where it needs to be. Once a JIT Inventory system is implemented correctly and has its bugs worked out, line pulls to stop the line traditionally drop off to a manageable level.

It’s important to note that a lot of success in a JIT Inventory system has to do with the culture in the manufacturing facility. Workers need to be aware of how the system works, what they can do to assist in managing the system and most importantly, they need to have a considerable amount of patience during the debugging of a newly-implemented line.

New Scheduling Site

We are launching a new site that I hope will be very informative.  The site contains information on manufacturing scheduling solutions as well as a collection of informative articles on MRP and lean scheduling.  I hope you will find it to be a valuable resource.  Check it out here and let me know what you think.  http://www.MANUFACTURING-SCHEDULING.COM

History of MRP

Some previous posts have started to lay out what Material Requirements Planning is and what to look for in a MRP system.  Today’s post will deal with the evolution of MRP.

MRP systems for inventory management first came about in the 1940’s, and became increasingly used in the 1950’s.

• The first MRP systems took a bill of materials for a specific finished product and exploded it into a production schedule and purchasing plan for the required components.
  Simple MRP
  • Focus on "order launching"
  • Used within production –not believed outside
• Before long, MRP was expanded to include information feedback loops so that production personnel could change and update the inputs into the system as needed.
  Closed Loop MRP
  • Focus on production scheduling
  • Interacts with the MPS to create feasible plans
• The next generation of MRP, known as manufacturing resources planning or MRP II, came about in the 1980s.  It added other functional areas or departments (such as engineering, accounting, marketing, finance, and human resources) into the planning process.
  MRP II (Manufacturing Resource Planning)
  • Focus on integrated financial planning
  • Treats the MPS as a decision variable
  • Capacity is considered (Capacity Resource Planning)
• A related concept that expands on MRP is enterprise resources planning (ERP), which uses computer technology to link the various functional areas across an entire business enterprise.
  ERP Systems
  • Common, centralized data for all areas
  • Implementation is costly and effort intensive
  • Forces business rules on companies 

Neat Blogs

We’ve been busy creating a few new sites and blogs, so today I’ll give you some links to the blogs; the links to the sites will come in a little bit.

 The first one deals with Key Performance Index (KPI).  We’re starting to get into KPI big-time, so you’ll hear lots more from us about it in the future.

We also have the following blogs:

• Agile Manufacturing Systems
• Total Quality Management (TQM)
• Open Source Manufacturing Execution Systesm (MES)
• Application Services
• Production Scheduling
• and finally, our Company’s Blog

Please take a look at them.  We’ll try to let you know when we’ve posted an article that would be of particular interest to those of you who are looking at this blog about Manufacturing ERP Systems and Manufacturing ERP Software.

What is MRP?

To discuss what MRP is, we’ll jump to the end result of the Material Requirements Planning process.  That end result is the finished product or finished goods.  Now while it may seem a little unusual to start at the end, that’s exactly where MRP starts. 

In systems work, it’s critical to understand where we’re trying to go.  Once we know where we want to go, we can try to figure out the best way to ge there.  But if we don’t know where we’re going, the odds are quite good that even the best plan won’t get us there.

MRP does this by starting at the finished goods and then working backwards from there.

We first look at the final result, the finished goods that are needed.  And then we ask “How do we get there?”.  In very simplified overview, we start to answer that question by looking at the production plan for these finished goods.  That in turn leads us backwards to the requirements for the subassemblies of these finished goods.  And since subassemblies are made up of components, we then look at these.  Then we finally get to the raw materials for those components. 

The purpose of all of this is to find answers to the following three questions:

• What is needed?
• How much is needed?
• When is it needed?

As Manufacturers, we’d like to produce as much income as possible. While there are many factors that contribute to our profitability, three that MRP systems address are:
How much can we produce?
Can we produce it on time?
And can we produce it with the least amount of inventory (both in actual use and left in storage)?

Future topics for this thread will include the inputs to the MRP (the Bill of Materials, the Master Schedule, and the records of the current inventory) and the processing (including the reports).  Other related posts will talk about the benefits of MRP and the history of MRP. 

Until then, here’s a link to an ERP software portal site.

See you then.

Thin Client ERP

What is the definition of Thin Client ERP? Thin client software refers to the relationship of the client (the end users’ computer) to the server where the software is stored and data is processed. A central server relays input information and feedback from and to the client machine. The opposite of thin client, thick client software performs most of the processing on the remote computer, then passes only data to be stored to the server. Many thin client devices run are capable of running from web broswers (referred to as browser-based software), because all significant processing occurs on the server.

 

 

This is beneficial since thin client computers are far less expensive than the computers needed to run thick client ERP software. Since most ERP systems are thick client, it can be difficult to find a thin client ERP system that includes the capabilites needed to optimize your business strategies. one software company that offers agile thin client ERP system is Tuppas Software, http://www.tuppas.com/erp-software/erp-software.htm. Tuppas is a company that specializes in modifiable software which maximizes a proactive team’s continuous improvement efforts.

 

 

In addition to cost savings on hardware, thin client systems provide many other advantages. Browser-based systems can be accessed from multiple locations without limiting the number of concurrent users. Upgrades and software changes occur at one location, so IT departments do not need to travel or spend time upgrading software on individual computers. Storing data in a central location and using the same software at all one’s facilities offers high-level views into business performance.

 

 

Thin client ERP is what all companies will be using in the next 5 to 10 years. Choosing a flexible system not only allows for growth, but also lets one take advantage of business opportunities and continuous improvement projects.