SmartAdvice: What To Look For In An ERP System

Ease of deployment is high on the list of attributes buyers of ERP systems look for, The Advisory Council says. Also, a look at services-oriented architecture, and common problems with knowledge-management projects.

Editor's Note: Welcome to SmartAdvice, a weekly column by The Advisory Council (TAC), an advisory service firm. The feature answers three questions of core interest to you, ranging from career advice to enterprise strategies to how to deal with vendors. Submit questions directly to smartadvice@tacadvisory.com

Question A: What attributes and features should a $2 billion electronics manufacturer look for from an ERP vendor?

Our advice: In a recent study that explored 16 attributes in four different phases of an application's life cycle, the attributes that were most critical were related to the ease with which the software solution was deployed. In contrast, the feature and function richness of the application, an area that many enterprises spend an enormous amount of time assessing, was generally given higher evaluation scores by users after the solution was in place. Thus, while features and functions are important aspects of any software purchase, they aren't likely to differentiate one "good" vendor from another. On the other hand, finding a vendor and a product that will take the pain out of the deployment phase of your ERP implementation may be of much greater importance.

Of the 16 attributes examined in the IT Alignment research that was conducted specifically on enterprise resource planning, ease-of-deployment and time-for-deployment were the two attributes that received the lowest average satisfaction scores across all vendors in the study. The nearly 500 companies that provided evaluations of their ERP vendor gave the products mediocre ratings on ease-of-deployment (3.2), and gave the vendors an overall negative score on time-for-deployment (2.8), using a 1-to-5 scale where 5 is very satisfied. Given the overall poor showing on these attributes, every enterprise should look closely at deployment capabilities when evaluating vendors.

Other attributes to be considered include ease-of-customization and ease-of-integration. The first of these, ease-of-customization, is an attribute that each organization must put into the context of what they want from an ERP solution. Many companies place a very high value on the ability to customize, but others see ERP solutions as a way to bring a best-practices approach to their organization, and are pleased to accept the standard methods and structures the application imposes on them. Ease-of-integration concerns your organization's need for seamless computing. If the ERP system cannot talk to the CRM system, and these two systems aren't easily integrated with the your current or future business-intelligence or business-process-management systems, you aren't going to get the value expected out of these investments. The attributes to focus on are those that affect the ease or difficulty your company will experience deploying the ERP system.

--Carey Azzara

Question B: What is a service-oriented architecture, and why should I be interested?

Our advice: Service-oriented architecture is a concept for efficiently delivering technology services with an end-user focus. Components of the architecture are designed to be interoperable and deliver services in a common visual and technical format. Web services are perhaps the most common implementation of SOA, and sometimes the two terms are mistaken for each other. The concept has gained tremendous market momentum in the last few years; almost all vendors are attempting to be compliant with standards which would allow for building an SOA. The ease of adoption or replacement of technical components (hardware and software) enables immense flexibility and speed in delivery of services.

Service-Oriented Architecture
SOA is a collection of services; all services have a way of communicating with each other. This communication can involve simple data hand-off, or handling of an activity by two or more services, and is facilitated by a middle tier of software known as middleware. Services are functions that are well-defined and independent, in that they don't depend on the state of other services. All services in a service-oriented architecture are loosely coupled to respond to a request for service through a common interface. This interface is a central piece of an SOA, and has to be designed at the initial stages of architecture development.

Service-oriented architecture isn't a new concept. It's been around in other forms such as Microsoft's Distributed Component Object Model (DCOM), and the Common Object Request Broker Architecture (CORBA). Today service-oriented architecture is most often associated with Web services. The two aren't necessarily interchangeable--Web services can be delivered without a service-oriented architecture, and a service-oriented architecture can be designed without Web delivery. Web services essentially use XML and adopt some of the standards to interface with other services.

The common standards that are most often associated with service-oriented architecture are:

Web Services Description Language (WSDL)

Universal Description, Discovery, and Integration (UDDI)

SOAP (Simple Object Access Protocol)

ebXML (Electronic Business XML)

Service-oriented architecture is a systematic approach to implementing applications where there's a lot of request and response interaction between multiple services. It comes at an additional cost of design and development effort, and requires the effort of integrating services at the middleware level. Simple applications where there is a one-way interaction, or the application is short-lived, wouldn't benefit from service-oriented architecture and its added complexity.

Among 688 respondents, 46% have deployed mobile apps, with an additional 24% planning to in the next year. Soon all apps will look like mobile apps – and it's past time for those with no plans to get cracking.