Purchasing of IT infrastructure technologies and services

Most IT projects require the procurement of hardware, software, or services. The purchase process entails determining what is needed, getting an offer, ordering, delivery, warranty and renewal. Each of these topics is described in the following sections.

Determine what is needed

Before any purchase can be made, it must be crystal clear what is actually needed. In most cases, a Bill of Materials (BoM) is made that includes part numbers of all items. It is a good practice to work with a supplier to get the BoM right the first time. The supplier can verify that all needed items are on the BoM, including small stuff, like cables, connectors, and mounting brackets.

Apart from the bill of materials, typically a Statement of Work (SoW) is made. A SoW describes what the supplier will do, apart from delivering the goods. For example, do we expect the supplier to build up a rack, place it in the datacenter, connect it to the power supply, label the cables, etc.? It must be clear from the start who does what to mitigate the risk of misunderstanding.

The supplier can also have specific requirements. For instance, is a loading dock available to deliver goods to the datacenter, or is the elevator large enough to lift the equipment to the final destination? Do not forget to ask for these supplier requirements!

Getting an offer

In a large organization, the lead time for the internal procurement process can be several weeks, or even longer. This lead time is due to the time it takes to find a supplier, to handle contract issues or to get signatures from management to instantiate the order. Often, after getting an offer from a supplier, procurement will try to get discounts, which could delay the process. So, check as soon as possible how long this process will take, to adjust the project planning accordingly.

It must be noted that apart from the lead time to get an offer, it typically takes four to eight weeks for the supplier to deliver the goods.

Choice of suppliers

Most organizations use preferred suppliers for standard purchases. Having a small set of preferred suppliers makes the purchase process easier – contracts are already in place, and discounts can be negotiated because of large volume purchases.

In practice, organizations often choose for a Microsoft and SAP unless policy for their software stack: when possible all software is either purchased from these suppliers, or built based on technology from these suppliers. Using a standard product line from one supplier eases integration of components. The alternative is using a best of breed landscape, where each component is chosen based on the best quality or the most comprehensive feature set. Sometimes an organization chooses a standard software stack for commodity components (like office tools, file and web servers, CRM systems and email servers), and best of breed products for highly specific tasks, that are close to the core business processes.

With hardware, predefined choices are typically made as well. For instance, all network equipment is from Cisco and all servers are from HP. One reason for this is easier management of support contracts – when a hardware component fails, one telephone number to the supplier’s support desk can be called to start the repair process. Another reason is to limit the knowledge needed in the organization to manage the components.

Having preferred suppliers can lead to a vendor lock-in; after some time it becomes unfeasible to change suppliers because of practical reasons. If all hardware is from Dell, for instance, then changing to another supplier – like IBM – is not good economics. The resulting lack of competition can lead to a higher price level in the long run and to a decrease in service levels. I have seen this in practice, where the preferred supplier was asked to deliver something and he just said no. The client had no choice but to say “okay then…”.

Bidding and tendering

Getting an offer may involve a bidding process, also known as tendering. For instance, a company policy could state that any purchase over $100,000 requires a bidding process. If the cost of a product or service is over this threshold, a rigid purchase process must be followed. The reason for a bidding process can also be a regulation requirement; for instance, many public sector organizations require a bidding process for large purchases.

In general a bidding process comprises the following steps:

  • RFI – Request for Information. In this step a large group of suppliers is asked to inform the purchase department if they are capable of providing the required goods or service. This step involves writing an RFI document and giving the suppliers time to respond. An RFI process typically takes two to four weeks.
  • Short list. In this step, based on the RFI responses, the purchase department creates a short list of suppliers that are most likely to be able to deliver the goods for a good price and with good service. A short list comprises typically three to five suppliers.
  • RFP – Request for proposal. In this step the suppliers in the short list are requested to make a proposal for the delivery. A full list of requirements is provided to them, including a draft statement of work. The suppliers typically get three to ten weeks to respond with an offer and a description of how they propose to provide the goods and/or services. There are often strict rules about the time table and the form in which the response must be given (for instance, all responses must be delivered in three-fold, before a certain date and time in person to the head of purchasing).
  • Questions and clarification. In this step, which is planned between the publication of the RFP and the supplier’s responses, the suppliers are given the opportunity to ask questions about the RFP (in writing), in case something is unclear or in case multiple options to fulfill a requirement exist. Usually, these questions and the answers are communicated to all suppliers on the short list. Most suppliers are therefore hesitant to answer questions, because it reveals parts of their offer to other suppliers.
  • Offer. Often at the latest possible moment the suppliers provide the answers to the RFP, including an initial offer. The purchase department checks the offers on completeness (are all questions answered, is the appropriate procedure followed) and price.
  • Terms and conditions negotiations. Next, the purchase department starts negotiations with the suppliers that provided the best response to the RFP – the preferred suppliers, mostly two of them. The terms and conditions of the delivery, including payment terms, warranty conditions, and discounts are discussed with them.
  • BAFO - Best and final offer. In this step the preferred suppliers make a final price and SoW, which is their last chance to change the offer.
  • Award. Based on the BAFO, the purchase department awards the supplier with the deal and the supplier can start to deliver.

As this list implies, this process can take a long time. I have been in such a process several times, and it is very time and energy consuming, both for the supplier and for the purchase department. At one occasion I was in a complex RFI/RFP process that took two years to complete!

Ordering

Ordering is mostly done by the purchasing department. They place the order and monitor the delivery time. When the order entails multiple delivery dates, a choice can be made to deliver the goods in partial deliveries or to deliver the goods in one delivery, but at a later date.

Because the delivery time is often weeks after the purchase order is placed, it makes sense to start ordering the goods as early as possible in the project.

Delivery

Some time after placing the order, the goods are delivered. For hardware, it is good practice to inform the department or person that has to physically receive the delivery well in advance. Beware that the person that physically receives the goods, is not always the one formally accepting the delivery.

The formal acceptance must be done by someone who is entitled to do so, often someone from the project that asked for the goods, or someone from the purchasing department. Before signing for delivery, check the boxes for any damage and check for completeness of the delivery!

Warranty

Typically a warranty period is one year for hardware and two months for projects. During the warranty period, defects will be fixed without additional cost. For projects, most of the time the project team will be gone after warranty period as well.

Renewal

When purchased goods are used for some time, they might need renewal. Hardware is often used for three to five years before it is replaced, and software typically has releases every few years. Service contracts are also often agreed upon for just a few years.

Sometimes a renewal of the hardware, software licenses, or service contracts leads to a new project.

Systems management should have Life Cycle Management implemented to handle the renewal, as each piece of hardware and software has its own life cycle. Renewal of service contracts is often managed by the purchase department.


This entry was posted on Tuesday 18 December 2012

Earlier articles

Infrastructure as code

My Book

DevOps for infrastructure

Infrastructure as a Service (IaaS)

(Hyper) Converged Infrastructure

Object storage

Software Defined Networking (SDN) and Network Function Virtualization (NFV)

Software Defined Storage (SDS)

What's the point of using Docker containers?

Identity and Access Management

Using user profiles to determine infrastructure load

Public wireless networks

Supercomputer architecture

Desktop virtualization

Stakeholder management

x86 platform architecture

Midrange systems architecture

Mainframe Architecture

Software Defined Data Center - SDDC

The Virtualization Model

What are concurrent users?

Performance and availability monitoring in levels

UX/UI has no business rules

Technical debt: a time related issue

Solution shaping workshops

Architecture life cycle

Project managers and architects

Using ArchiMate for describing infrastructures

Kruchten’s 4+1 views for solution architecture

The SEI stack of solution architecture frameworks

TOGAF and infrastructure architecture

The Zachman framework

An introduction to architecture frameworks

How to handle a Distributed Denial of Service (DDoS) attack

Architecture Principles

Views and viewpoints explained

Stakeholders and their concerns

Skills of a solution architect architect

Solution architects versus enterprise architects

Definition of IT Architecture

What is Big Data?

How to make your IT "Greener"

What is Cloud computing and IaaS?

Purchasing of IT infrastructure technologies and services

IDS/IPS systems

IP Protocol (IPv4) classes and subnets

Infrastructure Architecture - Course materials

Introduction to Bring Your Own Device (BYOD)

IT Infrastructure Architecture model

Fire prevention in the datacenter

Where to build your datacenter

Availability - Fall-back, hot site, warm site

Reliabilty of infrastructure components

Human factors in availability of systems

Business Continuity Management (BCM) and Disaster Recovery Plan (DRP)

Performance - Design for use

Performance concepts - Load balancing

Performance concepts - Scaling

Performance concept - Caching

Perceived performance

Ethical hacking

The first computers

Open group ITAC /Open CA Certification

Sjaak Laan


Recommended links

Ruth Malan
Gaudi site
Byelex
XR Magazine
Esther Barthel's site on virtualization


Feeds

 
XML: RSS Feed 
XML: Atom Feed 


Disclaimer

The postings on this site are my opinions and do not necessarily represent CGI’s strategies, views or opinions.

 

Copyright Sjaak Laan