Lesson 2: Systems Planning, Business Processes, and Feasibility

A systems project should begin with a clear reason for existing. This is called the business case. It explains why the organization should spend time, money, and effort on the project.

Project initiation usually starts when someone notices:

• delays in service
• repeated data errors
• weak reporting
• high operating cost
• poor user experience
• security or compliance issues
• lost opportunities for growth

At this point, the analyst should avoid jumping directly to a software feature list. The first job is to define the problem, the people affected, the impact, and the desired improvement.

A useful problem statement answers four questions:

1. What is happening now?
2. Why is it a problem?
3. Who is affected?
4. What improvement is expected?

Example:

The current permit renewal process of the municipal office relies on manual encoding and separate spreadsheets per unit. This causes repeated data entry, delayed approvals, and inconsistent records seen by applicants and staff. The problem affects front-desk clerks, reviewers, and business owners, especially during peak renewal periods. The project aims to standardize records, reduce turnaround time, and improve status visibility.

A business case becomes stronger when it links the project to organizational goals, such as better public service, improved productivity, lower operational cost, stronger decision support, and improved compliance and auditability.

Managers often approve projects not because the system is "modern," but because the project is justified.

A business process is a related set of activities that transforms inputs into outputs. In plain terms, it is the series of steps people follow to do work.

Examples:

• an enrollment process receives student data and outputs enrollment confirmation
• a clinic inventory process receives stock entries and outputs updated balances and alerts
• a loan approval process receives an application and outputs approval or rejection

Before designing a new system, you must understand the current process, sometimes called the as-is process. After improvements are proposed, you describe the to-be process.

When examining a process, ask:

• What starts the process?
• What steps happen?
• Who performs each step?
• What documents or data are used?
• Where do delays happen?
• Where do errors, duplicates, or rework happen?
• Which steps add value and which steps only consume time?

Common process problems include:

Sometimes the goal is not just automation but process improvement or even business process reengineering. Reengineering means redesigning the workflow more fundamentally instead of merely computerizing old inefficiencies.

For example:

• Bad idea: convert a six-signature paper flow into a six-screen digital flow
• Better idea: question whether all six approvals are really necessary

This is why analysts must study operations, not only screens and forms.