@ Supply Chain Management

Icon

What should an ERP software possess? Part deux…

In an earlier post: What should an ERP software possess, I was in the process of running up a list of things that an ERP innovator ought to think about. Today, I sat through a presentation of SAP Business One (More information about SAP Business One), an ERP software that SAP targets at Small and Medium sized enterprises (SME) and had the opportunity to brainstorm about critical features that a new ERP system ought to possess. I was expecting a watered down version of mySAP but Business One is a product offering that stands on its own. That particular feature is probably because of the fact that SAP acquired the previous seller of Business One and chose to retain the original offering instead of creating a watered down mySAP. An observation that jumped out at me is the number of forms and drill downs that Business One entailed and it just kept going and going and going and going… There’a lot of information embedded within the system and that’s probably what the system really brings to the table – a data backbone that everyone in the enterprise can use, modify and communicate about.
Meanwhile, I came across the following article: Lies your ERP system tells you. This article deserves a post in its own right but since I want to clarify some of the problems (thus translatable into opportunities) with the current state of ERP software.

“As a result, each year they were overstating the value of their inventory by millions of dollars,” Testa said. “They didn’t know what caused the problem and they didn’t want to find out, so they just wrote off the difference until the parent company called them on it.
“That’s the biggest problem with ERP systems,” Testa said. “People muck with them. They try to make them perform the way they want rather than the way that’s correct.”

What are the sources of the problem here? I can see at least two very readily – one being the lack of discipline when it came to data entry and the second more important one being the lack of understanding of the system. The latter is a point that was raised in the framework for how to think about a new ERP system. The former point about users lacking discipline in entering the data is something that I have frequently encountered while attempting to collect data in the pursuit of some consulting engagement – most of the time, the data sucks big time.

Its power depends on recording and tracking thousands of individual transactions, or events, ranging from sales orders to each component on a bill of materials. It then models how those processes interact with one another. Like dominoes in a row, each new transaction sets off a cascade of new events.

That couldn’t have been put more succintly. In fact, people should not be calling it ERP but information chain with the data layer called the data backbone. That’s what ERP essentially is – setting up a cascade of processes interacting, approving and alerting others is built on top of the information chain and data backbone. The easy way of determining whether a module/factoid/process is critical is to examine what happens to the whole when that little bit is compromised/affected/degraded.

ERP models reflect reality only when each transaction registers true. “Yes, it is costly to enter each transaction,” Testa said. “But as soon as you go around the system, it begins to degrade. Once that happens, people stop trusting it, and then they have another reason not to use it. It’s a death spiral that’s inherent in ERP: If you don’t trust the system, you validate that the system’s data is bad by screwing it up.”

Such remarks remind me about those who repeat – “You can’t manage what you don’t measure.” I’d guess that there is also a propogation of errors (and consequent magnification of errors) as it cascades through the entire set of interacting processes. As incorrect data sloshes throughout the system, it triggers actions and creates beliefs about the current state leading to inefficient decision making – that’s a beast that is difficult to corral.
Here’s a critical observation from the article:

That seems to happen most often when ERP systems reach down to the factory floor. There’s a disconnect.

Why, why, why? I harken back to a book that I am reading right now – Putting Total Quality Management to Work by Marshall Sashkin & Kenneth J Kise, wherein they report on Sam Walton’s (of Walmart fame) observation. The quote from the book reads, “Quality cannot be added on; it must be built in from the start. Mass inspection is completely off the mark. It assumes that quality can be achieved by identifying and then correcting errors. As Walton observes, this means that workers are paid to make errors and then paid again to correct them. This is not to say that workers like this any more than do managers. Deming notes that almost all workers want to do work of high quality, work in which they can feel pride and a sense of accomplishment.”
I am of the conviction that ERP, in its widely found form, is neither about Resource nor about Planning, it is primarily about Enterprise – a whole set of integral and connected processes across the enterprise are brought together under one umbrella (It might be an oddly shaped umbrella but the important thing is that it is one umbrella). The article, sort of, agrees:

Part of the problem is manufacturing complexity. “ERP is great for deploying standardized processes across an enterprise, but it has had a hard time bridging that last mile due to the complexity and disparity of plant operating solutions,” said Russ Fadel, vice president of manufacturing applications at SAP Labs LLC, in Palo Alto, Calif.

Remember, that standardized processes are the route that the current crop of ERP systems have taken – it was a choice in order to get that first “E” of Enterprise. Intuitively, that seems a logical choice but given the observation that there are some practical difficulties, it is wise to return to this original premise. Up to date information exchange is what is desired within an enterprise but it does not logically follow that standardized processes are the only solution. Here’s what really goes on in a wide-swarthe of companies that dot the ERP enabled landscape:

At worst, that means data and process models are scattered everywhere. At best, automated facilities use manufacturing execution systems that harmonize competing models and data, and moderate the flow of manufacturing information to and from the ERP system.

A lot of software providers have sprung up to fill the obvious shortcomings of ERP software. However, that leads to a multiplication and replication of data sources, data models, process models etc. But that’s the real world. Adopters of ERP systems ought to know this even if providers of ERP software do not.
There are three problems described in the article and they are:

“ERP does materials management and resource planning, but if you don’t have accurate shop floor data, ERP forecasts are not much better than putting your finger in the wind,”

and,

“Implementation,” he said, “is the number one, two, and three problem in ERP. It’s not that the systems are inflexible, but that they’re so very flexible.”

and,

“The conflict comes when companies try to reconcile what software says they should be doing with the way they’ve always done things,” Greenbaum said. “Companies that spend millions of dollars on ERP software would like to think that the software works for them and not the other way around.”

The above three reasons and others too are why I think that the business of ERP is in for radical competition. I can imagine that there are many product segments and industries that beg for competition – typically, they’re monopolies/oligopolies of some sort or the other.
But on the flip side, am I barking up the wrong tree? Am I confusing the problem of the technology with the problem of discipline and adaptation? Is the real problem the human element? Here’s why I’m thinking about that:

That sounds daunting. Yet every company operates at least one system where the data is always perfect, Boyer said. It is a system where everyone takes personal responsibility for accuracy. Where they report mistakes immediately. Where no one accepts any lies from their software.
It is, of course, payroll.
When operational personnel take as much responsibility for manufacturing data as they do for their paychecks, they will be able to count on their ERP systems to tell the truth.

Those are observations that are largely true and should give any observer pause. Perhaps the problem lies really at the interface of ERP software and the human being. Consequently perhaps, that’s where the solution must begin.

The expanded list as it stands now:
1. Implementation of the ERP system must be in a timeframe of months (even weeks – am I being rather optimistic) rather than years.
2. IT departments must be minimally involved in the setup and roll out of the ERP system – this is critical because often ERP is an IT project. However, it is an Enterprise project that uses IT as the medium – that’s a big difference.
3. Black boxes must be kept to a minimum if not eliminated entirely
4. Don’t get stuck into thinking that ERP systems should be modular, especially along the lines of defined functional areas. Other forms of organization such as inheritance (OOP) and value chains might offer alternative ways of organizing features/planning philosophy etc.
5. Meta modules and inherited modules must be available. A frequent thought that I have is that when people from different functional areas communicate, they’re abstracting what they think is happening in areas outside their expertise in order to understand those activities. I am thinking out loud here whether that is the nature of communication between functional areas as well.
6. Upgrades to the ERP system should be radically modified. I can’t think of a way to achieve this because the underlying philosophy of the system might change but the architecture initially outlined must consider both ongoing operations as well as future operations along the three broad areas above (Understanding, Adaptation & Implementation and Operation & Continuous Improvement)
7. Dashboards. Dashboards look cool. Other than that, it might very well be an information dissemination service to all members of the firm rather than decision makers.
8. Leverage open cooperation between ERP adopters and implementors across different industries and allow them to collaborate on process development, insights, measurement and continuous improvement ideas. In fact, allow them to exchange and adapt business ideas through the system. This idea is borrowed from the SCOR model implementation which is a formalized system for supply chain development and implementation.
9. The basis, methodology and guiding philosophy of the ERP system must be laid bare for everyone to encounter, experience and understand.
10. Data is the backbone of an ERP system. Therefore data integrity is critical and ways to preserve/enforce/structure data integrity is critical. Current ERP processes such as back flushing should be avoided as much as possible. One way to minimize (not eliminate data errors or significantly minimize data errors) data errors is to minimize direct key board related data entry by using combo boxes and drop downs instead of text fields for data entry.
11. Integrate the most commonly used software mediums into the system. If there is something that I hate about ERP systems is the Form based GUI. I hate it on two accounts (though at this time I cannot think how to replace it effectively) – first that IT has to be intimately involved in creating/modifying/adapting the GUI as it suits a company and second that you can only do what the form allows you to do even if it means cascading through numerous forms in order to ascertain what you want. What is the most commonly used software tools – it has to be MS Office/Internet Explorer or something of the sort. Ergo, the ability of individuals to use MS Office programs is going to have a distinct advantage over any ERP software providers ability to provide templates or customizable forms.
12. Understand why the interaction between ERP software and human actors causes these well documented problems. What is the solution there?

More to come…

Categorized as: Tools_, Supply Chain Management_
Tags: , , , , ,

What should an ERP software/tool possess?

The question that I ask myself today is not what particular features/functions an ERP must possess but what kind of experience must users as well as firms experience with an ERP software/tool? So, I decided to draw up a list of things that ERP software/tools must deliver in three broad experiential areas:
1. Understanding – A concept level requirement. Here the idea is that the assumptions, methodology of planning/calculation should be visible and easily understood by a firm’s management and/or users. This would mean that there are no black boxes that accomplish magical things or some dark art embedded within. From the competition aspect (i.e. with other ERP vendors), this throws open the inner workings of the system. Therefore, it will have to be tempered a bit – grey boxes that nevertheless explain in a simple manner what is being accomplished.
2. Adaptation & Implementation – Should a firm adapt its business processes to an ERP software or should an ERP software be adapted to a businesses processes? That is the basic question that underlies this area of Adaptation. Along with that arises the need for an ERP software to model the business process as it is or in a desired reengineered state. A frequent issues that I have observed is absurdly long implementation plans and projects which increases the risk of failures.
3. Operation & Continuous Improvement – An ERP system might be the backbone of an organization but it cannot be the system that only a backbone specialist only can contend with or change at a moments notice. The very notion of continuous improvement implies that any user should be able to change/improve the functioning or scope of an ERP system.
Now, admittedly, this is a rough cut of what I see an ERP must accomplish in order to be successful. From that broad classification of user experience, some ideas fall out as first cut rules that an innovator might follow:
1. Implementation of the ERP system must be in a timeframe of months (even weeks) rather than years.
2. IT departments must be minimally involved in the setup and roll out of the ERP system.
3. Black boxes must be kept to a minimum if not eliminated entirely
4. Don’t get stuck into thinking that ERP systems should be modular, especially along the lines of defined functional areas. Other forms of organization such as inheritance (OOP) and value chains might offer alternative ways of organizing features.
5. Meta modules and inherited modules must be available. A frequent thought that I have is that when people from different functional areas communicate, they’re abstracting what they think is happening in areas outside their expertise in order to understand those activities. I am thinking out loud here whether that is the nature of communication between functional areas as well.
6. Upgrades to the ERP system should be radically modified. I can’t think of a way to achieve this because the underlying philosophy of the system might change but the architecture initially outlined must consider both ongoing operations as well as future operations along the three broad areas above (Understanding, Adaptation & Implementation and Operation & Continuous Improvement)
7. Dashboards. Dashboards look cool. Other than that, it might very well be an information dissemination service to all members of the firm rather than decision makers.
8. Leverage open cooperation between ERP adopters and implementors across different industries and allow them to collaborate on process development, insights, measurement and continuous improvement ideas. In fact, allow them to exchange and adapt business ideas through the system.

That’s an attempt at a first list. Some of the above might seem outrageous and wishful thinking but if you’re going to set goals, they might as well as be as far out as possible. Next step – features.

Categorized as: ERP_, Tools_
Tags: , , ,

Shopping for an ERP system

How does one go about getting an ERP system? That’s what this article: ERP Shopping Tutorial from Managing Automation sets out to do. According to MA’s resident ERP expert Joshua Greenbaum, there are some initial steps that must be taken that are crucial to success when it comes to selecting the right ERP solution.
He elaborates that one must:

  1. Wrap your mind around the critical business issues your organization seeks to overcome by adopting new enterprise software.
  2. Make sure of stakeholder buy-in across the enterprise — from the plant floor to the top floor and all the key functional departments in between.
  3. Conduct an extensive integrator capabilities assessment.
  4. Data integration and migration is critical to successful implementations.
  5. Once these pre-requisites are covered, then — and only then — you can begin to explore the technical speeds and feeds of a new ERP software suite.

I posted the above initial steps that must be undertaken in order to select an ERP system because they’re threshold level hurdles any ERP software providers/start up must overcome in order to make the cut. However, they’re only initial hurdles and they’re are a number of architecture, implementation etc issues that need to be overcome as well.
As for a comprehensive list of ERP providers, Managing Automation has the magic list as well here.

Categorized as: Tools_, ERP_, Supply Chain Management_
Tags: , ,

What maketh an ERP software?

What maketh an ERP software system? An innocent question like this could subject you to a lot of harassment (sarcasm overfloweth here) – the magnitude and kind of undue attention would vary depending on the source of the attention. For example, an ERP salesman could subject you to a 3 hour presentation (If you’re like me and lose your mind after the first 15 minutes) and I shudder to think that it might happen not less than a week from today.
This site here lists some of the more common ERP modules that are available from ERP vendors:

  • SALES ORDER PROCESSING (SOP) and DEMAND FORECASTING
  • PRODUCTION PLANNING and MASTER PRODUCTION SCHEDULING (MPS)
  • ROUGH CUT RESOURCE PLANNING (RCRP / RCCP)
  • CUSTOMISATION PLANNING and ENGINEERING CHANGE CONTROL
  • BOM PROCESSING and DATABASE MAINTENANCE
  • PLANNING OF MATERIAL REQUIREMENTS (MRP)
  • PURCHASING (POP / Purchase Order Processing)
  • DETAILED CAPACITY PLANNING and SHOP LOADING and SCHEDULING
  • INVENTORY CONTROL (Stock Management)
  • SHOP FLOOR MONITORING and CONTROL (SFC / SFDC)

So I asked myself that if ERP were to be redone, who might the logical candidate be? I drifted towards an OpenSource implementation of ERP software. That led me straight to Compiere. A brief scanning of Compeire ERP’s architecture, features and processes led me to think that the seed has not fallen too far from the tree. Compiere is directed at SME (Small and Medium Enterprises) and that’s probably a smart move if you wanted to grow big.
The second stop was at OpenMFG which I found to be a lot more upfront about what it is they intend to achieve, what they offer and how they price it – i.e. a fresh breeze flowing from a vendor. OpenMFG has a lot of features as well which they have summarized smartly in their brochure.
The third (and final) stop was at ERP5. It seemed a lot more comprehensive in scale and scope than the previous two open source ERP offerings. The other thing that stood out was the ease with which ERP5 professed to carry out the installation and the availability of source code for the tool as well. I’ve found what I was looking for now. I’ll be exploring more features of the ERP5 tool now in order to study it in a little more depth and detail.

Several more Open source ERP software providers are listed here. I will take a brief jaunt through them as well in order to see what’s happening there.

As I was surfing the field of open source ERP providers, I came up with the idea of drawing up a list of ideas that would form the core of an ERP tool offering. If any of you reading this have any insight into ERP tools, have used them and would suggest your ideas, they would be more than welcome. My ideas in the next post.
Witnessing, a brief spurt in the offerings of entirely new ERP tools in an arena where the elephants of ERP (SAP and Oracle) reside and trample about leads me to think that the time is right to fell the elephants.

Categorized as: ERP_, Tools_, Supply Chain Management_
Tags: , ,

Taking a peek at mySAP (Transportation area)

This post is a continued peek into the capabilities of mySAP’s solution space. Transportation is one of the specialty areas of the firm that I work for (GENCO) and so I am more than familiar with all aspects of the transportation area and it should be a whole lot of fun exploring the capabilities of mySAP in this area. So let’s dive right in. There are three main areas in the Transportation solution space namely:
1. Transportation Planning
2. Transportation Execution
3. Freight Costing

Under Transportation Planning, there are five areas:
1. Collaborative Shipment Forecasting – Allows the firm to exchange/adjust forecast infomration between customers and carriers. Since forecasting really is the forward loop of the system, we should be observe a feedback loop (implicity or explicit) that should give back information to the firm and the other stakeholders about reality.
2. Load Consolidation – Any good TMS should have this feature because it is absolutely essential to realizing cost savings from transportation operations. mySAP comes with two options – one option is to carry out the consolidation yourself and the other is to allow the carriers to carry out the consolidation for which presumably you’d have to part with a portion of the savings so realized.

3. Mode and Route Optimization – Any good TMS should have this feature as well. What I would like to know is the internal workings of the Mode and route optimization algorithms, whether it relies on true optimization or some heuristic to achieve the mode and route optimized results. The other obvious question, given the high fuel prices and lack of carrier capacity, is whether this feature extends to the intermodal space or not.
4. Carrier Selection – Another important aspect of any TMS tool is to be able to assign and (and with the following feature of tendering) tender loads to carriers based on some business rules.
5. Collaborative Shipment Tendering – Most TMS come with this feature built in simply because it makes sense to do it. Either that or you’d have to be on the phone getting spot rates for lanes which is the least efficient way to tender large volumes of loads.

Under Transportation Execution, there are five areas:
1. Shipping – This option seems to be a souped up version of the Load Consolidation feature in order to move it from the Transportation planning to Transportation execution.
2. Collaborative Shipment Tendering – Repeated from Transportation planning area. I’m kinda getting ticked off with the repetition thing (not only because I might repeat myself needlessly but also because it inflates the number of features that a product advertises). Sure, it might not be possible to neatly categorize such a subject but that is a flaw in the presentation of the capabilities in neat little silos when such silo based differentiation is not the solution. C’mon SAP, you can do better…
3. Express Ship Interface – Deals with those orders that needs to be shipped out using the Parcel mode. However, I wonder what’s driving the logic of whether to send a particular shipment by parcel or not – whether the different modes of Ground, Next Day, Second day etc can be selected/optimized based on delivery dates or priority etc.
4. Distance Determination Service – There are only two service providers for distances – PC Miler or Rand McNally, that are used in the industry and most firms that I have dealt with use PC Miler of some version or the other.
5. Transportation Visibility – Since visibility is a key desire for many firms especially given outsourcing and longer lead times for the products produced in cheap manufacturing locations, this is a feature provided for tracking the movement of an order either by road or by sea.

Under Freight Costing, there are 4 areas:
1. Freight Cost Calculation – An entire industry of freight pay and audit works around this particular topic and this functionality is going to make inroads into their revenue pie.
2. Freight Conditions – A database of freight rates and accessorials that are applied to orders to evaluate the freight costs
3. Freight Cost Settlement – Classic execution of freight pay conducted from within an ERP system so that there is end to end supply chain management.
4. Freight Costing Extensions – Adjustment of freight paid with customers or carriers based on some outlined business rules.

So is anything amiss? Not really. mySAP’s transportation piece seems to have everything that I’d expect from a good TMS solution. The natural extensions that might be thought off from the current state are probably contract management with the transportation providers, integration of 3PLs as 3PLs and not as some virtual carrier to whom the loads are tendered, performance of the carriers as well as 3PLs, BI (Business Intelligence) from carrier performance that enables the identification of routes, modes and networks that could be leveraged for better carrier contracts. There is one component that will be of great value to an ERP provider such as mySAP that can leverage existing users through the internet and that is peer collaboration of transportation networks. And that can be entered into using an interface that mySAP could provide albeit for a small fee.

Taking a peek at mySAP (Strategic Supply Chain Design area)

What is the scope of mySAP’s solution space? While dealing with SCM, one has to meddle with the ERP system that one finds within a firm. mySAP is one of those leading ERP providers that is making inroads into the SCM space as well. Here is the solution space of mySAP as outlined on their website.
The main solution function areas are captured in the figure below (which I shamelessly copied from their site – I wonder where the jury of copyright matters rests on the matter?).


Each of the solution areas has its own mini-web site which explains some of the capabilities ensconced therein. So let’s go one by one starting bottoms up:

1. Strategic Supply Chain Design: Three areas under this category.

  • Supply Chain Definition : You can model every part of the supply chain (such as locations, transportation lanes, resources, products, and so on.) using the Supply Chain Engineer in SAP APO. The Supply Chain Engineer allows you to place locations on a map and link them with the corresponding transportation lanes and product flows. Furthermore, you can drill down to all elements belonging to the supply network, or request information about single or combined elements in the network. For example, you have the ability to see which products belong to a particular location. You can also add products to this location or modify the location’s master data. Master data can also be transferred from SAP R/3 bzw. SAP ERP using the Core Interface (CIF). Materials are limited in their validity and availability. This has to be taken into consideration throughout the entire supply chain management solution. A central maintenance instance for interchangeability relations is offered that provides information for all planning applications. This secures consistent planning of discontinued material stock before using follow-up material stock. For a service parts supply chain, the supply chain definition is extended with the Bill of Distribution, which not only describes a location hierarchy but also allows the modeling of virtual locations (which are physically the same locations as aggregation locations in the location hierarchy, but are logically only used to model the direct customer facing demand of those aggregation locations), virtual consolidation regions (to consolidate the demand of several locations for slow moving parts) and inventory balancing regions.

The Supply Chain Engineer in SAP APO sounds a lot like the tool that I developed (based on the transshipment model) that allows for strategic level planning for supply chain components. The great thing about the Supply Chain Engineer is the integration that it provides with the ERP system which is how it should be ideally.

  • Supply Chain Monitoring : The Supply Chain Cockpit (SCC) consists of a highly intuitive, graphical interface that acts as the top enterprise planning layer covering all planning areas such as manufacturing, demand, distribution, and transportation. All employees in the Plan -> Source -> Make -> Deliver cycle of supply chain management can use it to their advantage. As the gateway to SAP APO, the SCC makes dealing with a vast supply chain easier and more manageable. SCC allows you to:

About me

I am Chris Jacob Abraham and I live, work and blog from Newburgh, New York. I work for IBM as a Senior consultant in the Fab PowerOps group that works around the issue of detailed Fab (semiconductor fab) level scheduling on a continual basis. My erstwhile company ILOG was recently acquired by IBM and I've joined the Industry Solutions Group there.

@ SCM Clustrmap

Locations of visitors to this page

Subscribe by email

Enter email:
Delivered by FeedBurner

Enter email to subscribe
March 2024
S M T W T F S
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Archives