Processes, SOPs, Policies, Checklists and Systems: What Is the Difference?
Understand the distinct roles of processes, SOPs, policies, checklists and systems—and how they work together without creating unnecessary bureaucracy.
O04 · FOUNDATION ARTICLE · FIEASE BUSINESS OPERATIONS
A business owner says:
“We need an SOP for employee reimbursements.”
Finance creates a six-page document.
But employees still do not know what expenses are allowed.
Managers still approve claims differently.
The portal does not enforce spending limits.
Finance still receives incomplete documents.
Claims still take ten days.
The company has created an SOP.
It has not necessarily fixed the operating system.
This happens because several management concepts are frequently used as though they mean the same thing:
process, procedure, SOP, policy, work instruction, checklist and system.
They do not.
The distinction is not academic.
Each solves a different operational problem.
A useful starting point is:
Process = what happens from beginning to end.
Policy = the rules and direction governing the work.
Procedure/SOP = the specified way important work should be carried out.
Work instruction = detailed guidance for a particular task where that level of detail is useful.
Checklist = the critical things that must be verified or remembered.
System = the interrelated people, processes, technology, information, rules and controls that collectively create an outcome.
There is an important caveat.
Different industries, standards and organisations use terms such as SOP, procedure and work instruction somewhat differently.
ISO formally defines a procedure as a specified way to carry out an activity or process. OSHA, in one of its programme definitions, describes SOPs as detailed documents identifying responsible roles and giving instructions for performing specific tasks. FDA regulated environments also use SOPs as controlled written methods intended to create consistency and protect quality or data integrity. (iso.org)
So Fiease should not claim there is one legally universal document hierarchy.
Instead, we can create a practical hierarchy that helps businesses organise work clearly.
First, what is the simplest comparison?
Consider an employee claiming ₹8,500 for business travel.
The company needs several different things to make reimbursement work reliably.
| Element | Question it answers | Reimbursement example |
|---|---|---|
| Policy | What is allowed? | Hotel reimbursement permitted up to defined limits |
| Process | What happens end to end? | Claim → approval → Finance review → payment → recording |
| SOP / procedure | How is an important activity performed? | How Finance reviews an expense claim |
| Work instruction | Exactly how is a specific task performed? | How to enter an approved claim in the ERP |
| Checklist | What must not be missed? | Invoice, approval, purpose, amount, tax fields |
| Form/template | What information must be captured? | Expense claim form |
| Control | What risk must be prevented/detected? | Claims over threshold require higher approval |
| Record | What proves what happened? | Approved claim and payment reference |
| System | How does everything work together? | Employee + manager + portal + policy + Finance + bank + accounting |
All nine may relate to the same business outcome.
They are still not interchangeable.
What is a process?
A process describes connected activities that use inputs to produce an intended result.
ISO's current terminology defines a process as interrelated or interacting activities that use inputs to deliver an intended result. (iso.org)
For reimbursement:
Employee incurs eligible expense
↓
Claim submitted
↓
Manager approval
↓
Finance review
↓
Payment scheduled
↓
Employee paid
↓
Transaction recorded
That is the process.
The process is concerned with flow.
It shows how work moves from beginning to completion.
What questions should a process answer?
A useful process should make several things understandable:
Where does the process start?
Where does it end?
What are the major stages?
Who participates?
Where are decisions made?
Where does work move between people?
What output should result?
A process map may show all of this visually.
But it does not necessarily tell an employee every detail of how to perform each activity.
That is where procedures become useful.
What is a procedure?
ISO defines a procedure as a:
specified way to carry out an activity or a process.
Importantly, ISO also notes that a procedure can be documented or undocumented. (iso.org)
That means the concept of procedure is broader than a document.
A business may have a consistent procedure that employees know and follow even before it has been written down.
But when consistency, training, risk or governance matters, documenting it becomes useful.
Then what exactly is an SOP?
SOP means Standard Operating Procedure.
In practical business use, an SOP is generally a controlled written procedure describing how routine or important work should be performed consistently.
OSHA describes SOPs in one programme context as detailed documents identifying responsible personnel and providing specific instructions for performing tasks. FDA guidance in regulated environments similarly expects SOPs to be clear, controlled, authorised, kept current and representative of actual procedures in use. (osha.gov)
This gives us a practical Fiease distinction:
A procedure is the specified way of performing work. An SOP is usually the documented, standardised form of that procedure where consistency and control justify formal documentation.
That wording is safer and more accurate than claiming every procedure is automatically an SOP.
Is an SOP the same as a process?
No.
This is probably the most common confusion.
A process explains the end-to-end flow.
An SOP usually explains how one important portion of that flow should be performed.
Consider procure-to-pay.
The process may include:
Purchase need identified
→ requisition
→ approval
→ supplier selection
→ purchase order
→ receipt
→ invoice matching
→ payment.
An Accounts Payable SOP may explain:
How to validate and post a supplier invoice.
The process crosses departments.
The SOP may sit mainly inside Finance.
The distinction is:
Process = journey.
SOP = method for executing part of the journey consistently.
Could an SOP cover an entire process?
Yes.
Terminology is not rigid enough to prohibit that.
A small process may be completely described within one SOP.
But as complexity increases, it is usually clearer to separate:
high-level process flow
from
detailed operating instructions.
Otherwise a document becomes extremely long and difficult for users who need only one part.
What is a policy?
A policy defines organisational intentions, direction, rules or boundaries.
ISO's management-system terminology defines policy as the intentions and direction of an organisation as formally expressed by top management. (iso.org)
In everyday business operations, policies often establish questions such as:
What is permitted?
What is prohibited?
Who has authority?
What limits apply?
What principles must be followed?
For employee reimbursement:
Policy might state:
Eligible expense categories.
Maximum hotel allowance.
Whether alcohol is reimbursable.
Submission deadline.
Approval levels.
Documentation requirements.
The policy does not need to explain every screen the employee clicks.
That is not its purpose.
What is the difference between a policy and an SOP?
Consider travel expenses.
Policy
Employees may claim reasonable business travel expenses within approved category and monetary limits.
SOP
Finance reviewer:
opens submitted claim,
confirms business purpose,
checks documentation,
compares expenditure with applicable policy,
reviews approval,
accepts or returns claim.
Policy answers:
What rules govern us?
SOP answers:
How should the work be performed?
That separation is useful because policies and procedures often change at different speeds.
The expense limit might remain ₹X for two years.
The software workflow could change next month.
If policy and software instructions are unnecessarily mixed into one document, every system change forces policy-document revision.
Can a policy exist without a process?
Yes—but it may not be operationally effective.
Management can announce:
“All discounts above 15% require Commercial Director approval.”
That is a rule.
But then the process must answer:
How is the approval requested?
Where is it recorded?
How does Sales know it was approved?
Can ERP prevent unauthorised discounting?
What happens in urgent situations?
A policy without an operating mechanism may exist only on paper.
What happens when policy and process contradict each other?
Employees improvise.
Suppose policy says:
Director approval required above ₹1 lakh.
But the ERP allows managers to release ₹5 lakh without approval.
What is the real control?
The written policy?
Or the system?
The business has a governance gap.
Strong operations aligns:
policy,
process,
authority,
technology,
controls.
What is a work instruction?
“Work instruction” is commonly used for more detailed task-level guidance.
But unlike the ISO definitions for process and procedure, organisations do not use “work instruction” with perfect consistency.
So Fiease should use it as a practical documentation distinction, not as a universal legal taxonomy.
A useful distinction is:
SOP
Explains how a routine activity or procedure should be performed.
Work instruction
Explains a particular task in greater operational detail.
For example:
SOP: Vendor Invoice Processing
may cover:
receive invoice,
validate supplier,
match purchase order,
review receipt,
handle mismatch,
post invoice.
A work instruction might be:
How to post a three-way-matched invoice in SAP/ERP.
It could include:
fields,
screens,
codes,
sequence,
examples.
The work instruction is more task-specific.
Does every SOP need a work instruction?
No.
If the SOP contains enough detail for a competent user, adding another document creates duplication.
Use a separate work instruction when:
the task is technically detailed,
the software steps change independently,
different audiences need different detail,
safety/quality risk requires exact instructions.
Documentation should simplify execution.
Not create a library nobody can navigate.
What is a checklist?
A checklist is a verification or memory aid.
It answers:
What critical items must I make sure I do not miss?
For an expense claim:
Invoice attached?
Business purpose stated?
Correct approver?
Within policy?
Correct cost centre?
Bank details validated if relevant?
A checklist does not normally explain the entire operating method.
That distinction is fundamental.
Why use a checklist if employees already know the job?
Because knowledge does not eliminate omission risk.
A competent person may understand a process completely and still forget one important item.
Checklists are useful when:
there are multiple critical checks,
tasks happen under time pressure,
omission matters,
the user already knows how to perform the underlying work.
This is why checklists should not become mini-SOPs.
A checklist works best when it remains quick to use.
Can a checklist replace an SOP?
Sometimes for very simple work.
But usually they solve different problems.
Suppose a new Finance employee does not know how to review a vendor invoice.
A checklist saying:
PO ✓
GRN ✓
GST details ✓
may not be enough.
They need the method.
Conversely, an experienced reviewer may not want to reread a six-page SOP for every invoice.
They may only need the checklist.
Different tools for different users.
What is a system?
This is another frequently misunderstood word.
In business conversation, people often say:
“The system is SAP.”
or:
“We need a CRM system.”
Software is one component.
It is not necessarily the entire operating system.
ISO defines a management system as interrelated or interacting organisational elements used to establish policies and objectives and the processes needed to achieve them. Its public guidance explains that the complexity of such a system depends on the organisation and may range from relatively simple arrangements to extensive documentation and controls. (iso.org)
NIST similarly describes work systems as coordinated combinations of internal work processes and external resources required to develop and deliver products or services. (nist.gov)
For practical business operations, therefore:
A system is the wider arrangement through which people, processes, technology, information, rules, resources and controls work together to create an outcome.
Can an ERP work perfectly while the business system performs badly?
Absolutely.
Suppose the purchasing software performs every programmed function correctly.
But:
employees create vague requisitions,
approvals take four days,
supplier selection is inconsistent,
receipt confirmations arrive late,
invoice disputes are frequent.
The software is functioning.
The business system is not functioning well.
That is why:
system improvement ≠ software implementation.
Technology is one lever inside the operating system.
What is a control?
A control exists to manage risk.
Examples include:
approval threshold,
credit limit,
maker-checker rule,
system validation,
quality inspection,
bank reconciliation,
access restriction.
A control can be:
preventive,
detective,
sometimes corrective.
The important question is:
What risk does this control address?
If a manager cannot explain the risk, the control should be examined.
It may still be necessary.
But “we have always done this” is not a risk rationale.
Is every approval a control?
Often, but not necessarily a good one.
An approval may originally have been introduced after a problem.
Over time, business volume grows.
The same approval remains.
Now:
hundreds of low-risk transactions wait for one senior person.
The control reduces one risk while creating:
delay,
management workload,
bottleneck capacity.
Operational control design should therefore consider:
risk severity,
transaction value,
frequency,
alternative controls,
automation.
What is a form or template?
A form or template standardises information capture or presentation.
Examples:
purchase requisition form,
customer onboarding form,
project brief,
expense form,
meeting template,
CAPA form.
A good form ensures the process receives required information.
It does not necessarily describe what should happen with the information afterward.
So:
Form = capture.
Process = flow.
SOP = execution method.
What is a record?
A record is evidence that something happened.
Examples:
approved purchase order,
completed checklist,
quality-inspection result,
signed agreement,
payment reference,
training record.
This distinction matters in controlled environments.
Documentation tells people what should happen.
Records show what did happen.
ISO terminology broadly distinguishes documented information used to operate a management system from evidence of results achieved. (iso.org)
Can one business activity require all of these?
Yes.
Consider customer credit approval.
Policy
Which customers may receive credit, limits, escalation thresholds.
Process
Request → assessment → approval → ERP limit → order release → monitoring.
SOP
How Finance performs a credit assessment.
Work instruction
How to update approved credit limit in ERP.
Checklist
Documents and checks required before approval.
Form
Credit application.
Control
Higher-level approval above a threshold.
Record
Approved credit assessment and decision.
System
Sales + Finance + customer information + policy + ERP + controls + reporting.
That is why saying:
“Create an SOP”
may be an incomplete response to an operating problem.
You first need to know which layer is broken.
Why do SMEs confuse all of these concepts?
Because young companies usually build systems organically.
Someone creates an Excel sheet.
Someone writes a note.
An employee explains the process verbally.
A policy appears after an exception.
A new manager adds approvals.
Software is introduced.
Nobody creates an overall documentation architecture.
Eventually the company has:
policy documents,
process maps,
Excel trackers,
SOP files,
training slides,
WhatsApp instructions,
email rules.
All may contain parts of the truth.
None may be authoritative.
This is a knowledge-governance problem as much as a documentation problem.
Does an SME need hundreds of SOPs?
No.
This is one of the most important points in this article.
Formalisation should be proportionate.
ISO's process guidance explicitly states that there is no universal catalogue of processes that must be formally documented. Organisations should determine documentation needs based on factors such as size, complexity, criticality and accountability; documentation can take forms including written instructions, checklists, flowcharts, visual media and electronic methods. (iso.org)
That gives SMEs useful permission:
You do not need bureaucracy for the sake of looking professional.
You need enough documentation to operate reliably.
Which processes should be documented first?
Prioritise where failure matters.
A practical decision matrix is:
| Factor | Higher need for formal documentation |
|---|---|
| Frequency | Performed repeatedly |
| Risk | Failure has serious consequences |
| Complexity | Multiple steps/decisions |
| Variation | Employees perform it differently |
| Training | New staff struggle to learn |
| Dependency | Knowledge lives with one employee |
| Customer impact | Failure affects customers |
| Financial impact | Error affects margin/cash |
| Regulatory requirement | Documentation is required |
A simple low-risk activity may need only a checklist.
A complex, critical process may require:
policy,
process map,
SOP,
work instructions,
controls,
records.
Does ISO 9001 require every process to have an SOP?
No.
This misconception deserves explicit correction.
ISO's published process-approach guidance says organisations determine which processes need formal definition and how they should be documented according to context and risk. It lists several possible documentation methods rather than requiring one SOP format for every process. (iso.org)
Specific industries, regulations, customer contracts or internal quality systems can impose additional documentation requirements.
Those are separate questions.
Are SOPs legally required in India?
There is no universal rule saying every Indian business must have an SOP for every process.
Requirements depend on:
industry,
activity,
regulation,
licence,
quality standard,
customer requirement,
contractual obligation.
For example, regulated areas internationally can impose specific written-procedure requirements; OSHA's process-safety regulations and FDA-regulated laboratory environments provide examples of activities where controlled procedures are explicitly important. (osha.gov)
For Fiease content, the correct distinction should always be:
Operational recommendation ≠ statutory requirement.
Where Indian sector-specific law applies, that should be researched separately.
What should a good SOP contain?
There is no single format appropriate for every organisation.
But a useful business SOP often includes:
Purpose
Why does the procedure exist?
Scope
When and where does it apply?
Responsibility
Who does what?
Required inputs
What must exist before execution?
Procedure
What steps should be followed?
Decision rules
What determines different paths?
Controls
What must be checked or approved?
Exception/escalation logic
What happens when normal conditions do not apply?
Output
What defines successful completion?
Records
What evidence should remain?
References
Relevant policy, forms, systems or related procedures.
Governance information
Owner, version, effective date and approval where appropriate.
The exact level of detail should match user competence and process risk.
What makes an SOP bad?
Several patterns appear repeatedly.
It describes the ideal rather than actual work
Employees ignore it because it does not fit reality.
It is too vague
“Check documents carefully” does not tell the user what “carefully” means.
It is excessively detailed
The procedure becomes impossible to use.
It contains no exception logic
The first abnormal situation forces employees to improvise.
It duplicates another document
Two sources slowly become inconsistent.
It is organised around the software rather than the business outcome
When software changes, the whole operating logic becomes unclear.
Nobody owns it
Outdated instructions remain indefinitely.
Nobody can find it
A perfect SOP hidden in a folder does not control a process.
How detailed should an SOP be?
Use a simple test:
Could a competent person in the intended role use this document to perform the activity consistently without unnecessary interpretation?
If no, it may be too vague.
If the user must read fifteen pages to perform a two-minute routine check, it may be too detailed.
The goal is usable standardisation.
Not documentation volume.
Should SOPs include screenshots?
Sometimes.
Screenshots help when interface navigation is difficult.
But screenshots also become outdated quickly.
For rapidly changing software, consider separating:
business procedure
from
system-specific work instruction.
For example:
SOP: principles and workflow for creating a new customer.
Work instruction: exact CRM/ERP screens.
When software changes, the work instruction can be updated without rewriting the governing procedure.
Who should write the SOP?
The people who understand the work should be involved.
A quality manager can structure it.
A consultant can facilitate.
A department head can approve it.
But the procedure should be tested against the actual workplace.
ASQ makes the same point for process maps: people who perform the process should be involved in documenting the current state. (asq.org)
OSHA's process-safety guidance similarly recommends review by both relevant technical staff and operating personnel so written operating procedures are accurate and practical. (osha.gov)
People closest to work frequently know:
exceptions,
shortcuts,
failure points,
system limitations
that management documentation misses.
Should an employee be allowed to improve an SOP?
There should be a controlled improvement mechanism.
If employees discover a better method, the answer should not be:
“Ignore the SOP.”
Nor should it be:
“The SOP can never change.”
Instead:
raise improvement,
evaluate risk,
test change,
approve,
update standard,
communicate.
Standards create a baseline.
Improvement creates a better baseline.
What happens when employees constantly bypass the SOP?
Do not assume disobedience first.
Investigate.
Possibilities include:
SOP is outdated.
Process changed.
System makes compliance impractical.
Employees were never trained.
Procedure is too slow.
Exceptions are more common than expected.
The written method was never realistic.
Employee behaviour is data.
It may reveal a documentation or process-design problem.
Does following an SOP guarantee a good process?
No.
Imagine every Finance employee perfectly follows an invoice-review SOP.
But invoices arrive without POs because Procurement's process is weak.
Finance performs its procedure correctly.
Vendor payment is still late.
The SOP works.
The process does not.
This is why process performance must be managed above individual procedure compliance.
How should SOP performance be measured?
Do not measure only:
“Did employees follow the SOP?”
Also measure the output.
For example:
invoice processing time,
first-time-right,
exceptions,
supplier disputes,
late payments.
Procedure compliance is a means.
Business performance is the purpose.
What is the relationship between process and system?
A process is one connected path of work.
A system connects multiple elements and often multiple processes.
ISO describes a management system as interrelated organisational elements—including structure, responsibilities, policies, objectives and processes—working together to achieve organisational objectives. (iso.org)
So:
Process asks:
How does this work flow?
System asks:
What combination of organisational elements makes the outcome possible?
That is a larger question.
Why does this distinction matter when buying software?
Because businesses frequently say:
“We need a system.”
Then buy software.
But software cannot independently create:
clear authority,
correct policy,
good data,
effective roles,
appropriate controls,
process ownership.
Suppose a CRM is implemented.
But Salespeople still:
do not enter information consistently,
use personal spreadsheets,
have no qualification criteria,
do not update stages.
The technology exists.
The Sales operating system remains weak.
Software supports systems.
It does not automatically create them.
A Fiease documentation architecture
For growing SMEs, Fiease can use the following practical hierarchy.
This is a Fiease documentation model, not a claim that all standards require this exact structure.
Layer 1 — Policy
What principles, rules and boundaries govern the work?
Layer 2 — End-to-end process
How does the outcome move from start to finish?
Layer 3 — SOP / procedure
How should an important repeatable activity be performed?
Layer 4 — Work instruction
How exactly is a particular task executed where extra detail is required?
Layer 5 — Checklist / job aid
What critical points must be verified?
Layer 6 — Form / template
What information must be captured or presented consistently?
Evidence layer — Records
What proves execution or result?
Connecting layer — Business system
How do people, processes, technology, information, controls and external resources operate together?
This architecture prevents every problem being solved with:
“write another SOP.”
HYPOTHETICAL EXAMPLE: Employee reimbursement done properly
Consider a 150-person company.
Employees complain reimbursements take two weeks.
Management's first response:
“Finance needs a better SOP.”
Fiease maps the complete operating system.
It discovers:
Policy problem
Employees do not clearly understand eligible expenses.
Input problem
Claims frequently lack invoices and business purpose.
Process problem
Manager approval has no expected turnaround.
System problem
Claims arrive through email, WhatsApp and paper.
Control problem
Every claim, even ₹300, requires Finance Manager approval.
SOP problem
Finance reviewers apply different verification methods.
Information problem
Employees cannot see claim status.
Management now understands:
the SOP is only one part.
A better solution might include:
clear expense policy,
standard submission form/portal,
defined manager SLA,
risk-based approval limits,
Finance review SOP,
review checklist,
claim-status visibility,
electronic records.
One operating problem required multiple management tools.
That is why terminology matters.
HYPOTHETICAL EXAMPLE: Customer discount approval
Consider a B2B manufacturer.
Sales complains that discount approvals are slow.
Policy
Sales may approve up to 5%.
Sales Manager up to 10%.
Commercial Head above 10%.
Process
Quote created
→ discount assessed
→ approval if required
→ quotation released.
SOP
How Sales prepares pricing and discount justification.
Work instruction
How to submit approval in CRM.
Checklist
Margin checked?
Freight included?
Payment terms considered?
Special tooling included?
Control
CRM prevents quote release without required approval.
Record
Approval remains attached to opportunity.
System
Sales + pricing data + margin logic + managers + CRM + Finance information.
Now management can ask a better question:
Which component is causing delay?
Maybe it is not the SOP at all.
Maybe the policy threshold is outdated.
Maybe approver capacity is the bottleneck.
Maybe Sales repeatedly submits incomplete information.
Correct terminology improves diagnosis.
How should documentation change as a company grows?
A five-person company can coordinate informally.
The founder knows every customer.
Employees sit together.
Exceptions are handled verbally.
At 100 employees:
more handoffs exist,
new employees need training,
managers cannot remember everything,
customer volume increases.
The amount of formalisation should therefore grow with:
scale,
risk,
complexity,
staff turnover,
regulatory exposure.
But it should grow deliberately.
More documents are not automatically evidence of maturity.
Can you have too many SOPs?
Yes.
Common symptoms include:
SOP Final.docx
SOP Final New.docx
SOP Revised 2.docx
SOP Updated Latest.docx
Nobody knows which applies.
This is not standardisation.
It is uncontrolled documentation.
A mature document-management approach needs:
one authoritative version,
clear ownership,
change history,
effective date,
easy access,
retirement of obsolete versions.
In regulated contexts, formal controls can be even stricter. FDA inspection guidance, for example, looks for authorised changes, historical control, employee familiarisation, periodic review and consistency between written SOPs and actual practice. (fda.gov)
How often should an SOP be reviewed?
There is no universally correct “every 12 months” rule for all business SOPs.
Review frequency should depend on:
risk,
regulation,
process stability,
technology changes,
failure history.
Review should also be triggered by events.
Examples:
new software,
regulatory change,
new product,
role redesign,
audit finding,
recurring error,
serious incident,
process improvement.
Some regulated procedures may have explicit mandatory review/certification frequencies. OSHA's process-safety rules, for example, include specific requirements for covered procedures. (osha.gov)
Do not convert a sector-specific requirement into a generic rule for every SME.
What is the biggest mistake businesses make with SOPs?
Treating documentation as improvement.
A company experiences repeated mistakes.
Management says:
“Write an SOP.”
But why are the mistakes occurring?
Poor input?
Bad system?
Excessive workload?
Unclear decision rules?
Wrong skill?
Bad process design?
The SOP may help.
Or it may document the problem.
The better sequence is:
Understand the process
↓
Identify failure
↓
Find cause
↓
Redesign if required
↓
Then standardise the improved method.
Do not standardise waste.
What should be documented first: process or SOP?
For cross-functional or poorly understood work:
process first.
Understand:
start,
end,
major stages,
handoffs,
ownership.
Then decide which activities need formal SOPs.
For a very simple standalone activity, that level of process mapping may be unnecessary.
Documentation depth should fit the problem.
Should every policy have a process?
Not necessarily a dedicated process.
But a policy that expects behaviour usually needs mechanisms that make the behaviour possible.
For example:
Information Security Policy.
It may be implemented through many processes:
user access,
password control,
device management,
incident response,
vendor security.
Policy provides direction.
Processes operationalise it.
Should every process have a policy?
No.
A process does not require a separate policy unless rules or management direction justify one.
Creating a policy for every process would produce unnecessary bureaucracy.
Should every SOP have a checklist?
No.
Use a checklist where omission risk justifies one.
Do not create documents merely because a template says they should exist.
Should every checklist require proof of completion?
No.
Some checklists are temporary cognitive aids.
Others need records because:
risk,
auditability,
regulation,
quality evidence
requires proof.
Again:
context determines documentation.
What does “systemise the business” actually mean?
This phrase is often used loosely.
Properly understood, systemisation means reducing unnecessary dependence on memory, improvisation and individual heroics by deliberately designing how recurring work operates.
That may involve:
clear processes,
decision rules,
responsibilities,
standard methods,
information architecture,
technology,
controls,
measurement,
continuous improvement.
It does not mean turning every action into a rigid SOP.
A business becomes more systemised when it can repeatedly produce good outcomes without requiring the founder to personally coordinate everything.
What should an SME owner ask tomorrow?
Take one recurring problem.
For example:
supplier payments are late.
Do not immediately say:
“We need a payment SOP.”
Ask instead:
Is the policy clear?
What is the end-to-end process?
Where does work wait?
Are inputs complete?
Which activity needs standardisation?
Does the employee need an SOP or merely a checklist?
Is software supporting the process?
Are controls proportionate?
Who owns the complete outcome?
What evidence should remain?
That diagnostic approach prevents documentation from becoming a substitute for management.
Frequently asked questions
Is a process map an SOP?
No. A map primarily shows flow. An SOP primarily explains how work should be carried out. A document can combine both, but the concepts remain different.
Is a procedure the same as an SOP?
Not exactly. ISO defines procedure broadly as a specified way of carrying out an activity/process. SOP is commonly used for a formal standard written procedure. Organisations vary in terminology. (iso.org)
Is a checklist an SOP?
Usually no. A checklist verifies critical items; an SOP explains the method.
Is software a system?
Software is a technology system, but in business operations the complete operating system normally includes people, process, information, rules and controls as well as technology.
Is policy more important than SOP?
Neither is inherently “higher” in business importance. They serve different purposes. Policy provides governing direction; SOP provides execution guidance.
Can a small company operate without SOPs?
Yes for some work. But formal SOPs become valuable where repeatability, training, risk, quality or scale justify them.
Should SOPs be extremely detailed?
Only as detailed as necessary for reliable execution.
Should employees memorise SOPs?
Not generally. They should understand the process and be competent in their role. Critical instructions should remain accessible.
Can videos replace written SOPs?
In some contexts, video or visual documentation may be effective. ISO's process guidance recognises multiple forms of documentation, including visual and electronic methods. The appropriate format depends on risk, usability and governance needs. (iso.org)
Who owns an SOP?
A designated business/process owner should be accountable for its accuracy and maintenance.
When should an SOP be deleted?
When the procedure is obsolete, merged, automated or replaced. Obsolete versions may still need controlled retention where regulatory/audit requirements apply.
Is documentation itself a control?
It can support control, but a document sitting unread in a folder does not guarantee controlled behaviour.
The idea to remember
The words matter because the management problem matters.
Policy
tells people the rules and direction.
Process
shows how work moves from beginning to end.
SOP / procedure
defines how important repeatable work should be performed.
Work instruction
provides deeper task-level guidance where needed.
Checklist
helps prevent important omissions.
Form/template
captures information consistently.
Control
manages risk.
Record
provides evidence.
System
connects the whole operating mechanism.
The objective is not to create a larger documentation library.
It is to create a business where:
people understand what should happen,
information is available,
responsibilities are clear,
normal work is repeatable,
exceptions are manageable,
controls are proportionate,
technology supports the flow,
and performance can be improved.
That is the difference between documenting a business and building an operating system.
And it sets up the next question naturally:
Even with good processes and good documentation, how should a business decide whether its operation is genuinely efficient?
Because operational efficiency is much more than cutting cost.
FIEASE · BUSINESS OPERATIONS FOUNDATION SERIES