An ERP workflow decision often has several reasonable options: configure an existing module, purchase another service, build a custom component or combine these approaches. Write down the work that must happen before comparing products or development estimates.
Describe the process in observable terms
Map the trigger, required information, decision rules, approvals and final record. Include exceptions such as missing attachments, a rejected request or an unavailable external system. Identify the system that remains authoritative for customers, inventory or financial records.
Turn essential requirements into acceptance scenarios. For a purchase approval, one scenario might require the correct approver, a visible decision history and a clear route for returned requests. Keep preferences separate from requirements that would rule an option out.
Compare the full operating commitment
Microsoft’s build-or-buy guidance discusses the tradeoff between development control and ongoing investment, alongside purchased software’s deployment and licensing considerations. Apply that comparison to the complete workflow.
- Configuration: check whether standard fields, roles and workflow rules cover essential scenarios.
- Purchase: examine licensing, API availability, usage limits, support and data export.
- Custom development: include testing, hosting, monitoring, security updates and future changes.
- Integration: account for authentication, reconciliation, retries and ownership when either system changes.
Compare the same planning period and expected workload for every option. Mark uncertain costs as assumptions. A subscription estimate that excludes integration support and a development estimate that excludes maintenance are incomplete comparisons.
"In the past, we managed software; today, we design autonomous processes that AI executes for us. The future belongs to those who automate not just the tasks, but the decision-making itself."
Test the hardest requirement early
Use representative, sanitized examples to test the scenario most likely to invalidate an option. That could be restricted access across companies, an unusual approval rule or exporting usable records. Record what works through configuration, what needs customization and what remains unproven.
A hybrid choice may fit: keep a standard document register while building a specific routing component. Define the boundary carefully so that updates and support responsibilities remain clear.
Record the choice and the exit route
Capture the context, selected option and consequences in a short decision record, following the structure described in AWS architectural decision record guidance. Include rejected alternatives, an owner and conditions that would justify reconsidering the choice.
Before committing, establish how records, attachments and workflow history can be recovered or migrated. Review the GreatWork.ai catalogue, including Workflow, Business Process Mappings and Custom Field, against your scenarios. Use the custom module and integration overviews to frame any remaining implementation work.
I look forward to seeing how these developments will improve service levels and customer satisfaction in the freight industry!