Introduction to System Analysis

Types of Information Systems

18 min Lesson 4 of 10

Types of Information Systems

Not every computer system in an organization serves the same purpose. A cashier entering a sale, a regional manager reviewing monthly revenue, and the CEO deciding whether to enter a new market all need different information, at different levels of detail, at different speeds. Over decades of practice, organizations have converged on a set of recognized system types — each purpose-built for a specific organizational tier and decision-making style.

As a systems analyst, one of your first jobs on any project is to identify which type of system you are dealing with — or, if the client is asking for something new, which type it needs to be. That classification shapes the data requirements, the performance expectations, the user population, and ultimately the design.

The Organizational Pyramid: Information systems are traditionally mapped to a three-tier pyramid: operational staff at the base, middle management in the middle, and senior executives at the top. Each tier has fundamentally different information needs, and the system types below map almost perfectly to these tiers.

The information systems pyramid — from operational transaction processing at the base to executive insight at the top. ERP and CRM span multiple layers.

TPS — Transaction Processing Systems

A Transaction Processing System is the engine room of any organization. It captures and stores the individual events — transactions — that constitute the core business: a patient is booked, a product is sold, a payment is received, a parcel is dispatched.

Key characteristics:

Processes large volumes of routine, repetitive transactions
Demands high availability and data integrity (no lost bookings, no duplicate payments)
Users are operational staff — receptionists, warehouse clerks, cashiers
Transactions are typically short-lived and simple (insert/update one or a few records)
Response time is measured in seconds or less

Concrete example — City Clinic: When a receptionist books a morning appointment, the TPS records the patient ID, doctor ID, date, time slot, and status in the appointments table. It enforces rules: no double-booking the same slot, no bookings for suspended patients. If ten receptionists book simultaneously, the system must handle concurrency without corrupting data.

Analyst's focus for a TPS: Concentrate on data volume (how many transactions per day?), peak concurrency (how many users at once?), and integrity rules (what must never happen?). These drive the database design and the performance requirements.

MIS — Management Information Systems

A Management Information System takes the raw transactional data produced by TPS and summarizes it into structured reports that help middle managers monitor operations and make routine decisions.

Key characteristics:

Reads (and rarely writes) from the TPS database or a dedicated reporting store
Produces scheduled, predefined reports: weekly sales, monthly occupancy rates, quarterly headcount
Users are supervisors, department heads, and store managers
Questions answered are structured: "Did we hit our target? Where are we over-budget?"
Historical and current data; limited forecasting

Concrete example — Online Store: Every night, a batch job aggregates the day's orders from the TPS into a summary table. The operations manager opens a dashboard showing revenue by product category, order fulfilment rate (orders dispatched within 24 hours), and average basket size. If fulfilment drops below 90%, she knows to investigate the warehouse. The MIS does not tell her why — it tells her what.

DSS — Decision Support Systems

A Decision Support System goes further than reporting: it provides analytical tools — models, simulations, and what-if scenarios — that help analysts and senior managers tackle semi-structured or unstructured problems where the right answer is not obvious.

Key characteristics:

Combines internal data (from TPS/MIS) with external data (market prices, competitor feeds)
Supports interactive exploration: the user drives the analysis, not a predefined report
Contains analytical models: regression, simulation, optimization, scoring
Users are analysts, planners, and senior managers
Response time is measured in minutes, not milliseconds

Concrete example — Logistics Firm: A route planning analyst uses a DSS to model different delivery schedules for a fleet of 40 vans. She adjusts variables — number of drivers, fuel cost, delivery window constraints — and the system runs a vehicle routing optimization to show cost and delivery-time trade-offs for each configuration. No predefined report could answer this; the analyst needs to explore the decision space interactively.

Common confusion: Many people mistake a sophisticated MIS for a DSS. The key difference is interactivity and models. An MIS delivers fixed reports; a DSS lets users build and run their own analytical models. If a manager can only read what the system publishes, it is an MIS. If she can run a simulation, it is a DSS.

ERP — Enterprise Resource Planning

An Enterprise Resource Planning system is an integrated platform that consolidates the core operational and management processes of an entire organization into a single shared database. ERP removes the information silos that arise when Finance, HR, Supply Chain, and Sales each use separate systems with incompatible data.

Key characteristics:

Spans multiple business functions: finance, procurement, inventory, HR, manufacturing, sales
One consistent data model — a sale in Sales instantly updates inventory and triggers a finance entry
Highly configurable but expensive and complex to implement
Users exist at every level: clerks enter data, managers read reports, executives see dashboards
Examples: SAP S/4HANA, Oracle ERP Cloud, Microsoft Dynamics 365

Concrete example — Manufacturing company: When a production manager confirms a batch of 500 units, the ERP simultaneously decrements raw-material inventory, raises a procurement suggestion for the next batch, updates the production schedule, posts the labour cost to the ledger, and makes the units available in the sales module. All of this happens through one system, in real time, with one version of the truth.

CRM — Customer Relationship Management

A Customer Relationship Management system manages all interactions and relationships with customers and potential customers, with the goal of improving customer acquisition, retention, and lifetime value.

Key characteristics:

Central repository for customer contact details, history, preferences, and communication
Tracks the sales pipeline: lead → prospect → opportunity → closed deal
Automates marketing workflows: email campaigns, follow-up reminders, customer segmentation
Supports service teams: case management, SLA tracking, ticket routing
Examples: Salesforce, HubSpot, Zoho CRM, Microsoft Dynamics 365 Sales

Concrete example — Online Store: The CRM records that a customer browsed running shoes three times and abandoned one cart. It automatically sends a discount email two days later. The sales team sees that a corporate client has not reordered in 60 days (above the normal 45-day cycle), flags this as a churn risk, and triggers a personal outreach task for an account manager.

Comparison of the five core information system types: organizational level, users, key question, and decision type.

Where ERP and CRM Fit in the Pyramid

You may have noticed that ERP and CRM do not sit neatly on one pyramid level. That is deliberate — they are horizontal platforms rather than purpose-built systems for one tier:

ERP functions as a TPS for routine transactions (invoice entry, payroll run) AND as an MIS for management reporting (balance sheet, stock levels) AND it feeds DSS-level analytics modules. It replaces multiple vertical systems with one integrated platform. The trade-off is enormous implementation cost and complexity.
CRM functions as a TPS for call-centre reps logging interactions, as an MIS for the sales manager reviewing pipeline health, and as a DSS-adjacent tool for the marketing team running segmentation analyses. It is specialized to the customer-facing domain, unlike the organization-wide ERP.

Analyst implication: When a client says "we need a system to manage our sales," your job is to probe whether they need a lightweight CRM, whether their existing ERP already covers it, or whether they need something custom. Jumping to a solution without classifying the system type is one of the most common — and most expensive — mistakes in analysis.

Practical Classification Exercise

When you encounter a new system requirement, ask three quick questions to classify it:

Who uses it and what do they do? Operational staff entering data → TPS. Managers reading summaries → MIS. Analysts running models → DSS. C-suite reviewing dashboards → ESS. Customer-facing teams → CRM. Cross-functional processes → ERP.
What kind of decisions does it support? Routine, structured (book a slot, process a payment) → TPS/MIS. Semi-structured, analytical (price a product, plan a route) → DSS. Unstructured, strategic (enter a new market, merge two divisions) → ESS.
What is the data direction? Mostly writes with fast reads → TPS. Mostly reads from aggregated history → MIS/DSS. Reads and writes across the full organization → ERP.

Real-world complexity: Modern systems often blur these categories. A retail platform might have a TPS for order capture, an MIS dashboard built on top of it, a basic DSS for demand forecasting, a CRM for loyalty emails, and an ERP for back-office integration — all talking to the same database. Understanding the classification still matters because each layer has different performance, security, and user-experience requirements that drive separate design decisions.