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.”
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.
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.
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.”
- 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.
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.
|