How Does a Business Process Become Software? A System's Journey from Analysis to Production

Turning a business process into software means understanding its actors, data, decisions, and exceptions, then expressing them as a coherent data model, enforceable business rules, and a traceable workflow. Screens are the visible surface. Reliability depends on how records are created, who may change them, and how work resumes after a failure.

In TankDev's software engineering approach, business process analysis is the starting point for system design. The database provides durable memory, APIs define contracts, and integrations connect the operation to other systems. Automation performs repeatable work; AI is added where it demonstrates measurable value.

We will follow a customer request at an industrial equipment service company. The scenario is illustrative, not a real client success story. Its revision conflicts, missing documents, unauthorised approvals, and uncertain ERP outcomes nevertheless represent concrete production concerns.

The starting point: One job exists in four places

A customer emails about a failed machine. Its serial number is in an Excel sheet, photographs are in a WhatsApp conversation, and the service manager's approval is in another email. An operations employee re-enters the information into the ERP. When the customer asks for an update the following day, answering requires contacting three people.

The missing piece is more than a request form. Which asset is involved, what work was approved, who owns the next step, and how the ERP record relates to the request are all unclear.

Narrow the first release: collect the request and documents under one identifier, manage review and internal approval, create an ERP service work order for the approved scope, and close the job with technical completion evidence. Leave stock, accounting, and invoicing under ERP ownership. This defines both what the new system manages and where it relies on an existing system.

1. Understand the process before writing code

Requirements analysis goes beyond listing desired screens. Follow a recently completed job with the person who performed it. Then inspect one held up by missing information and another returned because something went wrong. Differences between the stated procedure and actual work become visible here.

For the service example, analysis must establish concrete answers:

• Actors: Who opens, reviews, approves, and performs the work? Who takes over when the owner is away?
• Data sources: Which system is authoritative for customers and assets? Who supplies documents? Does the same serial number appear under different customers?
• Permissions: Can technicians add review notes? Can someone approve work they prepared? May customers see only their own requests?
• States: Where does incomplete work wait? Are rejection and cancellation different? What evidence establishes completion?
• Business rules: Which documents are required for each operation? Which scope changes require renewed approval? Which currency and amount definition apply to a cost threshold?
• Connections and failures: What happens during an ERP outage or repeated email processing? Who resolves an operation whose outcome remains uncertain?

Workflow mapping makes actors, states, transitions, and exceptions visible. Domain modeling establishes precise terminology: a request, a service job, and an ERP work order are not the same object. A request may need review before becoming a work order; an ERP connection failure does not mean the customer request was rejected.

The existing process need not be automated unchanged. Three people re-entering the same serial number may reflect missing data sharing rather than a business requirement. After mapping current work, define the target process and agree with its owner which steps can disappear and which controls must remain.

This stage produces agreed scope, a shared glossary, a role-to-action mapping, and acceptance scenarios. “An approval module” becomes testable when expressed as “an unauthorised person cannot approve, and an earlier approval cannot authorise changed content.”

2. The data model creates the operation's memory

Customer → Request → Process → Approval → Document → Transaction is a useful list of concepts, but not a ready-made chain of tables. A customer can have many requests, a request many documents, and a scope several approvals. Flattening these relationships into one row makes later changes difficult.

Our core model separates these responsibilities:

• Customer and Asset: The authoritative customer reference and equipment being serviced. Do not assume a serial number is a sufficient identifier without verifying its source's uniqueness rules.
• Request and RequestRevision: A stable request identity and versions of changing information such as scope, quantity, or address.
• ProcessRun: Execution under a particular workflow version, including current stage, owner, and deadlines.
• Approval: The decision maker, time, applicable policy version, and approved request revision.
• DocumentVersion: Document version, type, storage location, and the request revision it supports.
• IntegrationOperation: The intended external operation, stable operation key, remote record identifier, and verified outcome. This business record is distinct from a SQL database transaction.

Figure 1. The record should establish what information an approval covered and which job an ERP operation belongs to.

In a relational database such as PostgreSQL, foreign keys prevent invalid relationships, unique constraints prevent unwanted repetition, and check constraints enforce suitable field conditions. Revision numbers, for example, should be unique within a request. Relationships must also preserve company scope in a multi-tenant system rather than relying on screen filters. The PostgreSQL constraint documentation explains how these controls operate.

An approval decision, state change, and event triggering the next step should be persisted together. A transaction commits or rolls back these local changes as a unit. It does not implement every process rule or automatically extend atomicity to the remote ERP.

3. Business rules become permitted state transitions

The successful path might be created → review → awaiting approval → approved → in progress → completed. A working system also defines missing information, rejection, cancellation, and change requests.

Here, completed means an authorised technician has recorded completion, the required completion document exists, and the ERP work-order link is verified. Creating an ERP work order alone does not establish that the service work has finished.

A transition does more than write a new value into status. Workflow logic checks the current state, user permission, required information, and record revision together. A bounded process can use an application-level state machine. A workflow engine may help with numerous long-running processes, timers, and changing flows; a separate engine is not mandatory for every project.

Suppose request R-1042 revision 3 is awaiting a manager's approval. While that screen is open, operations changes the asset or scope, creating revision 4. Approval from the old screen must not authorise revision 4. Check and update atomically, rejecting stale actions. A material scope change requires renewed review and approval.

Authorisation and RBAC meet business policy here. A manager role alone is insufficient: does the person belong to the right company or service unit, have permission for this operation, and satisfy any separation-of-duties rule? Enforce checks server-side on every request, following the principles in the OWASP authorisation guidance.

Exceptions become explicit behaviour:

• Missing document: Move the request to awaiting information, showing what is missing and who should supply it.
• Rejection: Preserve the reason and decision. Resubmission after correction does not erase the earlier decision.
• Unauthorised approval: Leave the state unchanged and record the access failure. Hiding a button is insufficient.
• Scope change after work starts: Preserve executed work and evaluate the proposed change. Moving status backwards does not undo an external operation.
• Repeated submission: Reuse the same idempotency key for the same logical operation. Different content under that key is a conflict, not another operation.

An audit log records who changed what and which revision was involved. Define retention, access, and protection against modification: an ordinary log table alone does not guarantee immutability. The OWASP logging guidance provides a technical reference for recording and protecting events.

Figure 2. Business state and integration state are separate. Approved and transferred to the ERP describe different facts.

4. No system operates alone: APIs and integration contracts

The service application may read customers and equipment from the ERP and create a work order for approved scope through a REST API. Documents may live in a separate file service. Each system needs defined data ownership and contracts for its peers.

For example, POST /requests/R-1042/approvals could receive:

{
  "expected_revision": 3,
  "decision": "approve",
  "comment": "Service scope and documents have been reviewed."
}

Identity comes from the authenticated session, not a role claimed by the client. When approving the request, the server can store the outgoing event in an outbox within the same transaction. A publisher forwards it to a queue and a worker calls the ERP. The transactional outbox pattern addresses the gap between saving data and publishing a message; it does not eliminate redelivery.

If the ERP creates the work order but its response is lost, do not declare failure as a known outcome. Persist an awaiting-verification state, query using the external operation key, or follow the ERP's idempotent retry contract. A local record alone cannot prove how many records exist remotely.

Retry transient failures within bounded attempts and duration. Invalid customers and unauthorised access do not improve through waiting. A worker receiving the same message checks earlier outcomes; unresolved jobs enter review with a reason and owner. Service staff should see what is pending and whether intervention is required, rather than raw error codes.

A webhook is an external event notification. Verify its signature or the authentication required by the contract and record its event identifier. After durable acceptance, acknowledge promptly and process longer work in the background. GitHub's webhook guidance provides a concrete example of delivery and queueing practices. Where delivery order is not guaranteed, old events must not move current state backwards; use version checks or reread the authoritative source.

5. Automation reliably repeats an explicit rule

Once the workflow and data model are clear, notifications, document generation, reminders, and reporting become natural automation opportunities. Each needs a defined trigger, input, outcome, and failure behaviour.

Generate an approved service document from the approved revision. Before sending a reminder, verify that the job is still waiting for that person. Prepare completion reporting only when the required technical evidence and verified ERP link exist. Scheduled work must survive an application restart.

Reporting requires shared definitions as much as totals. Separate time awaiting customer documents from internal review time. Do not casually combine reopened, rejected, and integration-blocked requests in one completion measure. Transition timestamps reveal which stage creates the bottleneck.

6. Not every problem needs AI

Is a required document missing? Does a cost exceed an approval threshold? Does the request belong to the correct company? Use business rules or a conventional algorithm when the answer follows from explicit conditions. AI should not introduce uncertainty in place of a clear rule.

Different service tasks may justify evaluating AI:

• Document classification: Identify whether an attachment is a service form, photograph, or another document.
• Computer vision: Help extract a serial number from an equipment label or, with appropriate data, assist damage inspection.
• Anomaly detection: Flag unusual repeat failures or service durations relative to comparable equipment.
• LLMs and semantic search: Convert free-text requests into structured fields and retrieve relevant technical documents by meaning.
• Decision support: Suggest checks to technicians with supporting sources while leaving operational authority outside the model's text.

For R-1042, an LLM might suggest a fault category from “the machine will not start.” If a serial number extracted from a photograph matches two catalogue entries, the system should not choose automatically. Validate model-produced fields and route uncertainty to a person. The model must not determine customer permissions, approval limits, or authority to execute a final operation.

Measure the decision to add AI: does processing time improve over a rule-based baseline, is field accuracy sufficient, and what happens to incorrect routing and review workload? Compare on held-out examples of real work, considering cost and the consequences of errors together. An AI component that has not demonstrated value should not be a prerequisite for the first release.

7. Testable behaviour is the evidence that analysis reached production

The strength of the design lies in tracing each rule to its data model, implementation behaviour, and acceptance test. “Changed scope cannot use an old approval” becomes a RequestRevision–Approval relationship, an atomic revision check, and a concurrent-user test. “One request must not create two work orders” requires an integration identity, an idempotency contract, and a lost-response test.

Make the pilot's acceptance conditions explicit:

• R-1042 cannot advance without the required serial number, and the user can identify the missing field.
• An unauthorised user cannot approve through a direct API request either.
• A manager viewing revision 3 cannot approve from that screen after revision 4 exists.
• Repeated events or transfer messages do not create another ERP work order.
• A lost ERP response produces a visible awaiting-verification state and safe reconciliation.
• Scope changes, decisions, and technical completion evidence remain traceable in the job history.

Figure 3. Requirement → design → verification → production feedback. Acceptance depends on demonstrated behaviour, not merely the existence of a component.

Migration requires more than importing spreadsheet rows. Preserve source identifiers, separate duplicates and broken relationships, and verify open-work status. Establish the authoritative system for pilot records instead of independently editing the same work in two places.

Production readiness includes permission tests, a migration plan, interrupted connections, worker recovery, and a restore rehearsal. Distinguish application rollback from data restoration. Reconcile restored data with work already sent to the ERP before restarting queues.

After release, use operation identifiers to connect requests, approvals, background jobs, and ERP records. Track oldest-pending-job age, review duration, correction rates, and verified completion alongside technical errors. Alert ownership, user support, and a named process-change owner are part of delivery. What production teaches becomes requirements for the next release.

For TankDev, the engineering deliverable is a working system

The deliverable brings together a process map, domain model, database rules, API contracts, permissions, integration behaviour, automation, and operating procedures. AI may be a useful component of that system; it does not replace system design.

We examine these parts in more detail in our articles on moving from Excel to business software, production architecture, AI automation, and custom model development.

Good software is more than the existing process transferred onto a screen. It defines where data originates, which rules apply, who may change it, how systems communicate, and what happens when something goes wrong.

Coding is one part of that journey. The central engineering task is turning a fragmented operation into a system whose state is understandable, whose decisions are traceable, and whose work can safely resume after failure.