Business Process Management
Business process management as a discipline, not a product category
Business process management is a management discipline. Gartner, as quoted by IBM, defines it as employing methods to discover, model, analyze, measure, improve and optimize business strategy and processes. IBM draws the contrast directly: unlike the automation technologies, which are primarily technology-driven, this discipline encompasses continuous collaboration between business and IT teams to model, analyze and optimize processes end to end. It is narrower than it sounds in one respect and broader in another, concerning repeatable processes rather than one-time scopes of work, and whole processes rather than individual tasks.
The lifecycle the discipline actually runs
IBM's lifecycle for the discipline runs from design through monitoring and back into optimization. Stage counts differ across IBM's own pages, so the arc matters more than the number.
Establish what the process is meant to do.
Represent the steps, owners and decision points.
Run it, by people or by software.
Measure the live process, then change the design.
What separates this discipline from the tools that serve it
Six distinctions do the work here. Each is a line the discipline draws between itself and the software categories that sit closest to it.
Discipline, not software
IBM presents this as a management discipline of modeling, analyzing and optimizing processes end to end, and describes the automation categories as primarily technology-driven. They are different kinds of thing, so buying one is not practising the other.
Processes, not tasks
IBM contrasts the scope directly: task management focuses on individual tasks, while this discipline observes the whole end-to-end process. A team optimising each step in isolation can slow the process it is trying to improve.
Repeatable, not one-off
IBM also separates it from project management, which refers to a one-time scope of work. The discipline applies specifically to processes that repeat, because repetition is what makes measurement and improvement meaningful.
Three main types
IBM names integration-centric, human-centric and document-centric variants. The third is the one document-heavy operations land in, where the artefact moving through the process is a contract, an invoice or a form rather than a record update.
Business and IT together
The definition itself encompasses continuous collaboration between business and IT teams. A mapping exercise run by one side and handed to the other produces a diagram, which is not the same thing as a managed process.
Measurement before change
Measure and improve are separate verbs in the definition, and they appear in that order. Optimising a process nobody instrumented is guesswork wearing the vocabulary of rigour, and it can optimise the wrong step entirely.
Working through the lifecycle on a real process
The lifecycle is abstract until it meets one process. These six moves are what running it once looks like in practice.
Find the process as performed, not as documented.
Represent steps, owners and decision points visually.
Look for handoffs, waits and rework loops.
Instrument it before changing anything.
Change a single step, then measure again.
Treat the loop as ongoing, not a project.
Who practises it, and where it lands in an organization
The discipline's definition encompasses both business and IT, so ownership sits on both sides. These are the roles altaFlow's own use-case pages name.
- Operations leaders streamline vendor onboarding and internal change requests, and gain control over cross-departmental processes.
- IT and platform owners reduce custom development requests and provide a governed, secure platform.
- Finance automates purchase order approvals, expense reimbursements and invoice processing; procurement handles vendor onboarding, purchase agreements and renewals.
The recurring shape across those pages is the same: the business side owns the process, and the platform side owns the means by which it runs.
Why processes resist being managed
- Compliance exposure grows, on altaFlow's own account, where approval decisions happen in Slack threads or verbal conversations with no retrievable record of who decided what.
- The same account names tool sprawl: approval requests in email, approvals in Slack, signatures in DocuSign, records in the ERP, each requiring manual reconciliation.
- Approval cycles stretch from hours to days, on altaFlow's own account, because documents sit in inboxes with no visibility and no service-level enforcement behind them.
- IT becomes a bottleneck of its own, since altaFlow notes that every time a routing rule changes, someone has to file a ticket and wait.
Practices that hold the discipline together under pressure
Four practices carry most of the weight. Each addresses a place where the discipline collapses back into ordinary project work.
Keep the discipline distinct from its technologies
IBM describes the automation categories as primarily technology-driven, and this discipline as something else: a management practice of modeling and optimizing end to end. Conflating them produces a tool rollout with a strategic name attached and no continuous improvement behind it.
Choose the type before choosing the software
IBM's three variants are integration-centric, human-centric and document-centric. A document-centric process, where a contract or invoice is the thing moving, has different requirements from one that mainly synchronises systems, and the choice determines what the tooling has to be good at.
Model the process visually before automating a step
IBM's process mapping outlines the individual steps, identifies task owners and details expected timelines. Automating an unmodelled process fixes its speed in place, including the handoffs that should have been removed first.
Instrument the process before optimising it
Measure precedes improve and optimize in the definition itself. Without instrumentation the loop has no evidence to act on, and each revision is an opinion about where the delay lives rather than a finding.
The discipline applied, in two documented cases
Both cases below are drawn from altaFlow's published customer stories and stay inside what those stories record.
Scaling billing operations at Prosegur Security USA
Prosegur Security USA put its billing document operations under management as the business grew, across a United States workforce the story puts at roughly 7,000 people
- Non-technical staff built and deployed their own workflows after minimal training
- Roughly 20,000 workflow transactions now run per year
Resulting in a billing team of three handling the volume the story says would otherwise have required nine, with the company quadrupling in size and no headcount added to billing operations, and fewer than two support contacts needed across three years of use
Rebuilding student administration at NewSchool
NewSchool of Architecture & Design ran applications, financial aid and enrollment on paper, with disconnected systems creating data silos between document management and student records
- altaFlow digitized the forms and routed them to the right departments
- altaFlow also integrated with the student information system and added built-in eSignature
Resulting in the institution reporting manual work down 95 percent and turnaround down 90 percent, with the 100 percent document-accuracy figure and the 40 reclaimed staff-hours per week both coming from altaFlow's own results bullets rather than from the university
The practitioners named in those two stories
James Craig Director of Information Technology
Craig is the named speaker for the NewSchool of Architecture & Design story, where staff had spent countless hours keying data from student forms. His summary of the outcome: 'We've reduced manual work by 95% and cut our document turnaround time by 90%.'
Jeffrey Rader Information Technology Director
Rader is the named speaker for the Prosegur Security USA story, and his account is about the tooling staying out of the way: 'It is a very, very intuitive product. I could show you how to build a workflow in about five minutes.'
How a document-centric process runs on altaFlow
For the document-centric type, altaFlow describes its own loop in four moves. These are altaFlow's platform claims, not properties of the discipline.
altaFlow pulls from Salesforce or captures a web form.
Conditional logic and dynamic tables assemble the correct version.
Approval and signature, every step tracked.
Into the system of record, with no re-typing.
Governance obligations that attach to a managed process
- Audit trails: IBM notes automation can provide an audit trail
- Retention limits: GDPR sets a storage limitation principle
- HIPAA Security Rule: Administrative, physical and technical safeguards for ePHI
- SOC 2: An AICPA examination of a service organization's controls
- Processing scope: GDPR covers automated and manual processing alike
- Card-data handling: altaFlow routes transactions through third-party PCI DSS processors
FAQs about business process management
Six questions that recur once a team starts treating the discipline as distinct from the software it buys.
Is this the same as business process automation?
No, and IBM draws the line explicitly. Automation is a strategy that uses software to automate complex and repetitive processes; this discipline is a management practice of modeling, analyzing and optimizing them end to end, and IBM describes it as primarily strategic rather than technology-driven.
How does robotic process automation relate to it?
IBM describes robotic process automation as automating routine, isolated, repetitive tasks by deploying rule-based scripts that emulate human interactions with applications, and states that it falls under the umbrella of business process automation rather than being the whole of it.
What are the three types?
IBM names integration-centric, human-centric and document-centric. The distinction is what predominantly moves through the process: system-to-system data, human decisions, or a document such as a contract, invoice or form that has to be produced, approved and stored.
Do we need to model a process before automating it?
IBM's process mapping exists for that purpose, outlining the individual steps, identifying task owners and detailing expected timelines. Automating first locks the current handoffs in place, so the model comes first even when the tooling is already chosen.
Where does process mapping fit in the lifecycle?
At the modelling stage. IBM describes it as visually representing a workflow through flowcharts, swimlanes and value-stream maps, with notation commonly following BPMN or UML, which is what makes the analysis stage possible at all.
Is no-code tooling enough for a document-centric process?
IBM characterises no-code as fully visual and aimed at business users, extensible only through templated feature sets, while low-code adds custom code for professional developers. The choice follows from whether the process needs extension beyond what templates cover.
Optimize your document workflows
From quick wins on day one to measurable impact in under 90 days.
