Printer Friendly Version
WEB LINK - http://www.networkmagazineindia.com/200611/coverstory02.shtml

Making the right IT deal

Deals are struck at the negotiating table. Dominic K reports on how CIOs go about picking the best vendor and technology at the most viable price point for their companies while taking care of the technical and commercial parameters

Enterprises have multiple options when it comes to choosing software or hardware. Vendors pitch for a deal and submit Requests for Proposal (RFPs) considering the various parameters that go along with a particular company’s needs. When it comes to the art of making the best possible deal for his company, perhaps the most important factor for a CIO to keep in mind is commercial negotiation and arriving at the best price while ensuring that the technology acquired is stable and yet unlikely to be rendered obsolete overnight by the winds of technological change. We examine what a CIO does as he deploys a technological solution looking at some of the most popular ones, namely ERP and database systems on the software side and servers on the hardware front.

In search of ERP excellence

Here a CIO needs to analyse a slew of technological parameters some of which are functionality, the roadmap of the product under consideration, the level of integration among the multiple modules that the product comprises, references of successful deployments—preferably from the same industry vertical, ongoing support, the price and how much it is likely to escalate as his enterprise’s IT needs grow and he has to add users or sites.

Chinar Deshpande, CIO, Pantaloon Retail (India) informs, “First, it is important to check the relevance of a vendor’s solution in the industry vertical that the organisation operates. After this we will look at the reference customers in a similar industry. I would perform a high-level gap analysis of our functional needs and the vanilla features of the ERP system as published in high-level brochures. It is important to understand the financial health of the vendor, its future technology roadmap, presence in India, implementation partners and list of global clients.”

During the evaluation process, to start with, health check diagnostics should be conducted within the organisation to gauge how prepared it is for an ERP implementation. It is wise to postpone the deployment until the underlying infrastructure in terms of hardware, networking and trained manpower exists to support the same. Many ERP implementations fail not because of technical defects in the software but because an organisation is simply not ready for an ERP system yet.

Anwer Bagdadi, CTO, CFC International India Services says, “Organisations should take a 360 degree view of their IT needs before they settle on the vendor and technologies to be deployed. To begin with, an enterprise should analyse if it needs an ERP-based solution and not fall for marketing gimmicks. The need should be carefully analysed and there should be conviction that it will leverage business processes.”

Things to watch out for in an ERP deployment
The following areas are likely to result in budget overruns. These hidden costs need to be budgeted for before signing on the dotted line
Parameters Factors
Training Training employees on the latest updates and technologies. Responsibilities need to be fixed as to who’s going to do the training—the system integrator or the company’s IT team following a train-the-trainer approach.
Customisation The application has to be customised based on the enterprise’s operational processes and needs. The complexity added by customisation is an issue for organisations implementing ERP systems. An ERP system is already a complex system, requiring massive amounts of organisational change as part of the implementation process.
Data Analysis Large chunks of hidden enterprise data must be unearthed for precise decision-making. The organisation must decide if it wants to deploy analytical components as part of the ERP system or if it wants to go for full-fledged BI or even Analytical CRM.
Data Conversion The cost involved in converting data residing in various formats and the conversion of transaction data from a legacy system to the deployed ERP system has to be kept in mind. This is basically the Extract Transform Load (ETL) part of the deployment (or pre-deployment) wherein data is extracted from the plethora of databases and other sources in which it exists in most organisations that have not gone in for an ERP system.
Integration and Testing The cost involved in testing and integrating applications with other enterprise applications using Web services and middleware. This includes the ability to port data to reporting and Web enabled e-commerce applications along with the middleware application components.
Post-Implementation woes The cost involved in fine tuning the applications after the deployment. Performance may not be adequate as users get added or are brought on stream.

Justifying the decision

So what drives an enterprise to go about deploying an ERP-based solution? The answer can broadly be stated as the need to integrate an enterprise’s financial and customer order information. To standardise and speed up manufacturing processes, reduce inventory being carried out and standardise human resources processes and data stores.

It is critical for an enterprise to figure out if its ways of doing business will fit within the realms of a standard ERP package long before an implementation commences. The most common reason that companies walk away from multi-million-dollar ERP projects is that they discover, late in the day, that the solution offered does not support an important business process.

Under such circumstances, an organisation is left with two options. “It can change the business process to accommodate the software. This will mean introducing deep changes in long-established policies and processes. This may shake up important people’s roles and responsibilities in the organisation. The other viable option is to modify and customise the software to fit the process. This slows down the project, and makes upgrading to the next release excruciatingly difficult because the customisations will need to be torn apart and rewritten to fit each new version,” says M B Sam, Director, Marketing, Sun Microsystems India.

Best practices to be considered
Parameters Factors to analyse
Clustered environment For the database layer deploying a clustered environment helps reduce downtime and avoid business losses.
Application layer Various applications need to be load balanced for horizontal scaling. Some packages will have the functionality built into them while others will require that an external load-balancer be deployed.
Backup network The backup network should be deployed on a separate VLAN (Virtual LAN) or in a split mirror topology. This will complement business continuity if the primary link fails.
Headroom About 50 to 100 percent of headroom should be there on the database server for scaling up in the future.

Budgeting analysis

ERP projects have a vast scope. In addition to budgeting for software costs, financial executives along with the CIO should plan to cover aspects related to consulting, process reworking and integration-testing. Underestimating the price of training users with their new job processes can lead to an initial slowing of operations as it involves cultural changes. A few oversights in the budgeting and planning stages can lead to ERP costs spiralling out of control, sometimes faster than in most other information system undertakings.

Getting the database layer right
No ERP system can function without a robust database to store data for its system modules and custom applications built on top of it. Choosing the right database will require the following factors to be considered: multi-version read consistency and a variety of indexing schemes, options for partitioning with local and global indexing and the capability to self-tune applications.

There is no generic thumb rule defined to arrive at an infrastructure sizing for a database, it depends upon the application that runs on it, the number of users, usage pattern, batch vs. OLTP (Online Transaction Processing) load, query pattern (ad hoc vs. tuned queries) to name a few. Most vendors have a series of questionnaires to understand and analyse enterprise requirements. This, in turn, translates into infrastructure requirements.

Arun Ramachandran, Head, Presales & Professional Services, Sybase India & SAARC informs, “A CIO should have a clear idea of the application that will run on the deployed database solution. The deployed solution should be able to function under critical loads and heterogeneous computing environments. Inherent features and limitations should be well understood prior to a deployment.”

Choosing vendors

A CIO needs to choose the right vendor based on previous experience. The reputation of the vendor and the position he holds in the market as well as cost considerations, product architecture and technology offered have to be analysed

A CIO needs to choose the right vendor based on previous experience. The reputation of the vendor and the position he holds in the market as well as cost considerations, product architecture and technology offered have to be analysed before the choice is made. Due consideration should be given to understanding if the offered solution can be deployed without major changes in the existing IT infrastructure.

In a large enterprise both the functional and IT heads will participate in the decision-making process. Whereas in an SMB, the individual IT head will have to take most of the decision within strict budgets given to him.

Sridhar Padmanabhan, Vice-president, Corporate Automation, i-flex solutions says, “The entire selection procedure for us is managed, controlled and led by a group comprising functional heads and the IT team. They drew periodic feedback from other functional areas as and when needed.”

Vendor selection flow typically includes
  • Initial discussions with all the vendors
  • Response to RFI
  • Demo with relevant sample data (given to essential business users)
  • Technical evaluation and comparative study
  • Final negotiations

Decision-making process

The decision-making parameters differ based upon organisational structure and size. Bagdadi informs, “In a large enterprise, the organisation’s functional and IT heads participate in the decision-making process. While in an SMB, it is mostly observed that the individual IT head takes most of the decisions within strict budgetary limits offered to him.”

In spite of initiatives to introduce digital tender forms and RFI (Request for Information) and RFP the procedures to choose a vendor are predominantly paper-based. In a BPO outfit, typically no RFI is raised as requirements are specific and these organisations ask vendors for RFPs. Once vendors are short-listed, a detailed product evaluation follows. Some organisations have introduced Web-based processes although these are limited to the initial RFI clarifications.

Taking a spin

A product demo is an important step in the evaluation process. Product demos help experience the look-and-feel of a product, flexibility, user-friendliness and performance.

For a demo to be effective organisations can prepare their business operations and processes that cover the entire business cycle, right from enquiry to the shipment stage and pass this data on to the vendors. During the demo, enterprises should concentrate on the core functionality in a product and whether the offered solution is in tandem with organisational objectives.

The core objectives of a product differ from organisation to organisation based on its vertical presence. For example, in manufacturing the products are made-to-order, and hence an organisation looks for an ERP solution that is configurable.

The Underlying Hardware
Servers are the de facto necessity for every enterprise for its operational and functional needs. To begin with, server configuration should be done in terms of deployment architecture (centralised or distributed). Servers can be blades or rack mounts. Blades are increasingly making sense particularly if the deployments are above a certain size.

CIOs should consider parameters such as energy consumption and space required. Rajesh Dhar, Country Manager, Technology Solutions Group, HP India Sales says, “CIOs should consider and analyse the TCO (total cost of ownership) for three years down the line. Holding on to a myopic vision will not contribute to higher returns. On the contrary it will drastically hit operational performance.”

Organisations should consider server sizing based on customer inputs and best practices followed for a particular application. The output of the same can determine the resource requirement for the infrastructure layer. Coupled with this, the remote access features desired by a customer should determine the server selection. The cost of running a server infrastructure might outrun the cost of acquiring it over a period of three to four years. Enterprises should calculate the TCO and not limit itself to the cost of acquisition.

CIOs should not look at just the price and performance. The focus should be on parameters as performance per watt per rack unit of space. This will give them a better picture of running costs such as expenditure incurred on power and space.

Infrastructure

The infrastructure should be deployed in such a way that it complements the internal architecture of an ERP package. Typically, most packaged ERP systems have a three-tier architecture that consists of the primary database, the application and the presentation layers. The database layer tends to be a monolithic, single instance that grows vertically (SMP).

The application layer runs application instances and scales horizontally while the presentation layer runs the Graphical User Interface. Apart from this three-tier architecture, other components are the development environment, and training as well as a sandbox environment for testing & quality control.