Enterprise Planning & Structure

Save
ERP system planning attempts to make disparate systems work as one enterprise for a company.
ERP system planning attempts to make disparate systems work as one enterprise for a company. (Image: computers network image by Orlando Florin Rosu from Fotolia.com)

For many large organizations processing data and referencing information from thousands of records, enterprise resource planning (ERP) has become the approach du jour toward managing these resources with information technology. The goal for many is to be able to share information assets without hiccups or territories, thus augmenting the capabilities of the organizational team working together. Much depends on the ERP structure and planning chosen.

Goals Matter

Companies entering into the realm of ERP should know from the get-go what it is they want ERP to do for them before purchasing it. ERP projects are not off-the-shelf software; they provide customized system management that cannot be easily reversed after the fact. This critical point gets lost as a company focuses only on efficiencies and assumed business process cost savings promised by ERP packages.

Goals also include mapping out realistic results. Companies need to be honest with themselves and critical of designers regarding what efficiencies will actually be gained and on what schedule. Too often companies have very quick expectations that don’t match systems once they are implemented.

Planning

Planning and design drive an ERP structure. Like any organizational project, a company needs to take into account all existing processes, demands, reasons and shortcomings of the way it currently does business. This should be mapped out in detail, not summary-level descriptions.

With the goals clearly identified, design and technical planning should then bridge existing processes to the benefits of ERP within the goal parameters. Expectations of service delivery should also be framed within the capabilities of the design chosen. When implemented, no one should be surprised at the end product or results if designed correctly.

Software Acquisition

Management will need to choose from two categories of ERP software. The first category involves acquiring a system coded and created to match that business’ needs. The second category involves hiring a system and fitting that existing, outsourced ERP mold. This second approach may seem cheaper in price, but it can be much more difficult for a business to learn someone else’s way of processing data. That in turn can drive up initial costs. Businesses choosing the second approach should map out anticipated long-term costs since the company will be subject to the vendor host for as long as the hired ERP is in place.

ERP Limitations

Management and influential end-users must understand that typically an organization cannot change the software design of an ERP package once it is in place. If implemented, the ERP approach actually locks a company into one format, which may competitively hamstring that organization from being flexible versus its competitors.

Management will also need to structure for significant training on both maintenance and programmatic use. This drives training costs and ongoing help line support charges. If maintenance and support costs are not budgeted for in planning, an ERP system can then create an unplanned for cost drain to an organization.

Components

If planned properly and depending on goals, existing business processes studied and the acquisition approach, an organization’s ERP structure should address data production, hardware and software needs, capacity, procurement, implementation and change management and administrative integration. All of these areas will be referencing a main database with subcategories of storage and varying levels of access and delivery to field peripherals. Overseeing the whole approach is one administrative center controlling the platform, maintenance, security and software resource delivery.

Ongoing Support Required

Management should also make sure the planning structure includes an ERP help and support system. Too often all the resources are piled into design and development, with little left for training and troubleshooting afterward. Then, as mistakes happen, duct tape approaches are used to fix them, eventually corrupting the data and the system. Too much ad hoc changing or workarounds destabilizes an ERP and makes it worthless for the organization.

Related Searches

References

Promoted By Zergnet

Comments

You May Also Like

Related Searches

Check It Out

Are You Really Getting A Deal From Discount Stores?

M
Is DIY in your DNA? Become part of our maker community.
Submit Your Work!