Capturing Costs with ERP

Why is it so hard to capture project cost in ERP?

July 27, 2012
Reason #1: Disparate Systems Reason #2: Multiple divisions/locations Reason #3: Multiple modes of operation Reason #4: Usability The Solution

If you are involved with engineer to order (ETO),  design fabricate install (DFC), configure to order (CTO) or even make to order (MTO) manufacturing, you almost certainly have a hard time capturing and managing project costs in your enterprise resource planning  (ERP) software.

In nearly every company I visit, I have seen disconnected finance, engineering and manufacturing systems that prevent real-time visibility of budgeted versus actual costs in ERP.  A solution to this problem is usually one of the main things they are looking for in a request for proposals (RFP).

In the end, I have found that there are four reasons why manufacturers so often struggle to leverage their ERP systems to adequately capture and manage their project costs. Resolving these issues is the key to ensuring profitable and successful manufacturing projects.

Reason #1: Disparate Systems

One of the greatest barriers to accurately capturing project cost is the fact that many project-oriented companies are running multiple enterprise solutions in different parts of their business.

There are a number of reasons why a business may find itself using more than one ERP systems. Merger and acquisition activity, for example, can certainly leave a business with complicated or redundant software pairings. So too can organic growth into new markets that are not adequately addressed by an existing software package. Some businesses also pursue a best-of-breed software strategy that involves purchasing multiple point solutions that each address a different part of the business.

It is essential for enterprise software used in a project environment to allow for comprehensive roll-up of project costs, as is shown here in IFS Applications.

These disparate systems may force a business to spend hours or even days to obtain things like daily logs and reports including materials data, incident reporting and time reporting. This leaves someone managing a project from a desk perspective without knowledge of the exact number of hours or the exact cost that has been incurred during a certain time period.  They don’t really have a true picture of everything until the end of the day, the end of the week or in some cases the end of the month.

Reason #2: Multiple divisions/locations

Companies with multiple divisions and locations often have difficulty capturing project cost. Any industry that has a lot of global locations, or people working in very remote locations, will be hindered in this regard. This is often a hardware-related issue. If a company lacks the technical infrastructure to offer true global ERP, run on a single instance of the software, a single database and a single server, they will not have real-time visibility into project cost.

Reason #3: Multiple modes of operation

Some businesses, like manufacturers that operate in make-to-stock, make-to-order and engineer-to-order modes, are always running in multiple modes of operation with multiple business models. Others, including mining, utility or oilfield service and machinery companies, may run in different modes of operation at different points in a business or asset lifecycle. With a single business application not designed to handle this diversity, it can be difficult to manage multiple modes or multiple stages of an asset lifecycle.  This means that many of these businesses are running multiple ERP products to suit each mode. This in turn throws up the barriers that make it difficult to track project cost.

Reason #4: Usability

Even when a company has a single system in place that is designated as the system of record, it may not be used widely by people throughout the organization. The single most likely reason for this will be a lack of intuitive usability. Throughout an organization, many employees frankly don’t care what the person in the C suite or front office worries about or what software they would like to force them to use. So often, despite the best intentions of management to institute a single system, data used to support day-to-day operations remains in disparate systems, presenting a barrier to adequate, real-time cost capture and control.

The Solution

The difficulty many executives experience in adequately capturing project cost is a direct result of the fact that project management software is not a native part of their ERP system. They may be running some type of project management software that is integrated to some degree with their ERP application, but this integration is not complete or thorough enough to provide full visibility into important metrics like committed cost.

The logical solution is to select and implement highly usable enterprise software designed for the project environment, with project management functionality that shares data, in a natural, event-driven way, with the rest of an enterprise suite. Identifying this software during a selection process will require extensive due diligence. The effort required to examine in detail the project capabilities of each ERP package will pay dividends in the end, however, in the form of increased project control and profitability.

Project ERP must enable on-demand forecasting, monthly reviews and simulation to accurately visualize and capture cost trends on projects.

What to look for in ERP software

Usability and the ability to handle multiple modes and locations are essential traits. But naturally, the presence of truly native and embedded project management functionality is the core trait that ERP for project environments must offer. And there is a tremendous value difference between ERP with native project management and a point-to-point integration with external project management software. ERP vendors may claim to offer the former but in fact offer the latter. So it pays to ask a lot of hard and pointed questions to ensure that data in fact flows freely between project management and the rest of the application set. Some of these questions may include:

  • Is the demand for the project schedule driving the material demand schedule?
  • Are my purchase orders truly connected to that project?
  • As something changes on the purchase order, how is that change reflected in the project?
  • If the budget changes, does the budget impact what I have committed on purchase orders?

Carrie Ghai is a senior business software consultant with IFS North America. She has been in the enterprise software industry since 1996. Prior, she held a number of positions in industrial firms including Vice President of Customer Service in North America for Tetra. She holds an accounting degree from Ealing College of Higher Education and qualified as a Certified Accountant (UK).

Sponsored Recommendations

Voice your opinion!

To join the conversation, and become an exclusive member of IndustryWeek, create an account today!