IT infrastructure technology is the set of physical devices required to operate the entire enterprise
Today, most system and application software is custom built by in-house programmers
Systems integration means ensuring the legacy systems work with new elements of the infrastructure
A mainframe is a type of legacy workstation.
Client/server computing is the most widely used form of centralized processing
Application server software is responsible for locating and managing stored Web pages.
Using an online storage service such as DropBox is a type of virtualization
In cloud computing, rapid elasticity refers to the ability of computing resources to be quickly altered to meet demand
A private cloud is operated by single organization but may be managed by a third party and be located of premises
A computer language translation program is an example of a system software
Hypertext markup language specifies how text, graphics, video, and sound are placed on a document
HTML5 is the latest evolution of HTML, and is designed to make it much easier to embed third-party add-ons, such as Flash animations, in web pages.
Web services can exchange information between two different systems regardless of operating system or programming languages on which the systems are based
XML is limited to describing how data should be presented in the form of Web pages; HTML can perform presentation, communication, and storage of data.
The collection of Web services that are used to build a firm's software systems constitutes what is known as a service-oriented architecture
SaaS providers deliver and provide Web-based, remote access to storage.
Allowing departments to make their own software and hardware purchases increases efficiency and minimizes the need for centralized support.
Total cost of ownership components include costs for downtime, training, and support.
One of the main benefits of moving to mobile business computing platforms is the dramatically lower costs of hardware
Software localization refers to the entire process of converting software to operate in a second language
In a(n) ___________ computing model, companies use their own infrastructure for essential computing for less critical operations or additional processing during peak business periods.
A) scalable
B) quantum
C) autonomic
D) hybrid cloud
Software that manages the resources of the computer is called:
A) system software
B) application software
C) data management software
D) network software
Software used to apply the computer to a specific task for an end user is called:
A) system software
B) application software
C) data management software
D) network software
Software that organizes, manages, and process business data, such as data concerned with inventory, customers, and vendors, is called:
A) system software
B) application software
C) data management software
D) network software
Legacy systems are still in use today because:
A) they can only be run on the older mainframe computers.
B) they are too expensive to redesign
C) many integrate well using new Web services technologies
D) they contain valuable data that would be lost during redesign
What would be a reason for using a workstation rather than a personal computer?
A) when you need more powerful computational abilities
B) when you need to access a network
C) when you need to serve applications and data to client computers
D) when you need to share resources
Which of the following types of computer would you use to support a computer network?
A) server
B) mainframe
C) workstation
D) PC
Which of the following types of computer is used for weather forecasting?
A) mainframe
B) server
C) minicomputer
D) supercomputer
Connecting geographically remote computers in a single network to create a "virtual supercomputer" is called:
A) co-location
B) cloud computing
C) grid computing
D) autonomic computing
The use of multiple computers linked by a communications network for processing is called:
A) grid computing
B) distributed processing
C) client/server computing
D) centralized processing
Updated: Oct 31, 2022
When it comes to procurement analytics, the question of whether to build it yourself or buy it from an external service provider has been a long-standing debate.
In analytics build-or-buy decision-making, you need to consider various perspectives and form an educated TCO estimate. According to the Gartner Information Technology Glossary, TCO is:
“A comprehensive assessment of information technology (IT) or other costs across enterprise boundaries over time. For IT, TCO includes hardware and software acquisition, management and support, communications, end-user expenses and the opportunity cost of downtime, training and other productivity losses.”
Therefore, TCO is more than just a price tag. It looks beyond the hardware and software acquisition to assess the full costs associated over the lifespan of use.
In this article, TCO will be broken down into three main themes related to spend analytics:
- Acquisition and development cost: the costs related to the acquisition, maintenance, and development of a spend analytics software solution, as well as their inherent opportunity costs.
- User experience and functionality: the costs related to the training, onboarding, and support of users and the impact on productivity.
- Data management and quality: the costs related to the long-term management of data, including data architecture, data quality, and data security.
Under each of these themes, there are various factors to consider and compare.
See what Spend Analysis software has to offer with this complete guide for all levels.
Total Cost of Ownership in Procurement Analytics
Even though this is an age-old topic, its specific application to the procurement analytics context is less talked about. There is still room for improving the overall understanding of what to consider when building or buying analytics solutions.
Certain cost elements may come as a surprise for an organization along the way. Organizations may not have taken all elements into account in the initial budgeting equation. To avoid hiccups like this, we’ve compiled a full list of considerations.
We define these two strategies as follows:
The “Build” Solution: An in-house managed, custom-built solution for one organization or business unit. Sometimes completed with the help of subcontractors, the operators remain internal.
The “Buy” Solution: An externally sourced, ready-made solution from a proprietary software vendor. The final product for users will largely be the same across organizations, with variations in applications and modules based on industry or customer needs.
When choosing to buy, you can split that decision into two sub-paths: buying what you can build and buying MORE than you can build. If you buy what you can build, the choice will save time and resources but not provide much value beyond that.
Buying MORE than you can build means you are accessing features that are value-added services outside the scope of what can feasibly be built in-house. In the case of spend analytics, these services might include AI classification, benchmarking databases, or self-service visualizations.
Keep in mind that sometimes, “buying” means subscribing, as in paying a subscription fee for a licensed SaaS product.
There are many considerations in build or buy. Companies may prefer the build option because of a desire for better control and to address their specific needs and level of complexity. Often, building in-house is seen as the only way to fulfill these needs.
The resources needed to build, though, are substantial and require domain-specific competencies. Meanwhile, buying a software solution can itself be a time-consuming and expensive process that still might not satisfy what users were hoping to achieve. There are multiple factors to consider on this topic. The primary consideration should be Total Cost of Ownership (TCO).
The complete list of TCO factors to build or buy analytics
The table below shows the full list of factors related to each TCO theme.
Now, let’s break down each consideration in more detail:
Acquisition and development costs:
- Sourcing cost: The literal “price tag” and costs related to acquisition. With building, there are no sourcing costs. Market benchmarking and development will generate the most costs. Buying will require a competitive tender and a good amount of market research.
- Cost transparency: The ability to estimate the associated costs now and in the future. Building software may lead to surprising cost elements that have a budget impact along the way. Time, talent, and resources are harder to measure than a sticker price. Buying software benefits from economies of scale, which means the price is usually lower.
- Opportunity cost: The loss of time and resources that could have been used elsewhere. Building software takes a long time. Buying from a software provider, on the other hand, allows for testing the solution through a proof of concept (POC) first. Seeing the solution in action can minimize the opportunity costs because it can also be used as a starting point for the full implementation.
- Data cleansing costs: The costs associated with the cleansing of input data in analytics. If choosing to outsource this task alongside a built solution, costs can easily get out of hand. Vendors typically take care of this sort of input data cleansing during implementation, and you benefit from procurement experience in multiple industries.
- Data enrichment costs: The costs associated with adding external data or third-party data in analytics. While a solution provider can act as a bridge for connecting your data to external data ecosystems, doing it on your own requires more storage and architecture considerations.
- Maintenance costs: The cost of infrastructure and maintenance. Building a solution doesn’t end with deployment—it can include continuous maintenance costs. Vendors bear this burden for you.
- Development costs: The costs of updating the solution with new technologies. With the rate of change in technology, software must be continuously updated. This will also include keeping up to date with market developments. It will be challenging to consider all the needs of the organization and prioritize and justify decisions. Buying a solution means you are gaining benefits from the vendor’s developments with the market and working with multiple clients’ ideas and problems.
- Feature scalability: The costs of adding new analytics features. When building, new features can require large amounts of work, sometimes requiring returning to the drawing board entirely. From the vendor’s standpoint, they want to offer new features and be synergistic with other software in the market. Scaling the solution can be as easy as buying more functionalities.
- Capabilities: The use of talent put towards development. In building procurement analytics, you need to consider the capabilities in terms of aligning with the wider data strategy and procurement-specific knowledge. Vendors can offer expertise in both these domains.
User experience and functionality:
- Time to market: The expected timeline of implementation. Users probably needed the proposed solution yesterday, and building can take a substantial amount of time to do right. Buying is a much smoother journey to market.
- Control of customization: The degree of freedom to tailor the analytics solution. Building a solution can be fully tailored to your organizational needs and is completely in the hands of developers. While vendors may know the wider market needs of various customers, there’s always the chance you won’t find a 100% fit for your needs.
- Training and support: The resources dedicated to feedback, training, communication, and documentation. This is an important but often overlooked consideration: how much time will it take to teach users how to use a solution? Luckily, vendors work hard to make sure training materials are available and can continuously support users along the way.
- Service level: The resources dedicated to maintaining the quality and performance of the analytics solution. While vendors have service level agreements (SLA), it can be tricky to discuss unmet expectations with an in-house solution.
- Partnership: The possibilities for collaboration with partners for new features. With building, you are on your own—or limited to your own alliances. A procurement analytics vendor can be a partner in your digitalization journey and open more network possibilities than were possible on your own.
- Scalability of users: The ease of growth in user base. How scalable is the software? Can it grow with the company? Bought solutions are highly scalable and can easily grow with your business needs.
Data management and quality:
- Data security/ data privacy: The ability to meet all necessary INFOSEC regulations. Vendors have tested their infrastructure and their other customers have similar concerns, so it needs to be bulletproof. Some vendors will offer data security and privacy covering everything from GDPR-S to HIPAA, meaning you won’t need to hire your own cybersecurity experts to keep up with the complexity of regulations.
- Data location: The decision of where to store the data. There may be concerns or regulations regarding which region or country the data is stored in. With a build option, you have complete control over the data location if this is an issue. Legacy strategies may still apply to sensitive information, but average companies are moving towards the cloud trend.
- Data architecture: The consideration of how to align an analytics solution with the wider IT architecture and strategy. If all your relevant data is stored in one place, such as a data warehouse or data lake, it’s possible to build software on top of that which feeds the data directly to the application. However, there are costs involved in buying servers or cloud capacity, and fully on-premises storage may create further restrictions. When purchasing software, it is possible to connect to both data warehouse/ data lake strategies or directly to ERPs. Buy options offer flexibility in data architecture.
- Data quality: The continuous effort to ensure superior data quality and gain value from that data. This should be a major consideration. Whether building or buying, the data quality must remain good—it is the pre-requirement for users to gain value from the solution.
Will you build or buy your procurement analytics solution?
In software development, the build or buy debate was resolved decades ago. Most organizations turn to vendors for almost all their business software needs.
But the same trend has been slow to happen in procurement analytics. Why is that?
IT departments may argue that they know their systems or users better, but the market space is in constant change and user requirements are evolving.
Buying a solution that serves a purpose for the time being doesn’t rule out the option to build better-fit in-house solutions later.
If the organization needs to harness the potential of its data now, they do not want to wait for years of development.
Serving existing user needs now and evaluating alternative development avenues later is not a duplication of effort: it is a step along the way in your organizational maturity.
By understanding the total cost of ownership (TCO) of the build or buy decision, you can make the best choice for your current needs.
Interested in learning more about how to work collaboratively with IT and ensure end users get the solutions they love using? Then read more in our full-length eBook Procurement Loves Data.
Photo credit: iMattSmart, Unsplash