compliance, another enters data, an- other approves exceptions, and an - other answers the customer. Each of- fice may perform its part reasonably well while the end-to-end process still fails. Process-mapping methods such as Business Process Model and Notation can help when used with discipline. The notation matters less than the conversation. Teams need enough shared language to distinguish tasks from decisions, internal handoffs from external exchanges, data objects from systems of record, and human work from system work. The map should make implicit decisions ex - plicit. If several arrows leave one ac- tivity box, a hidden decision probably is buried inside the task. That hidden decision is exactly the kind of logic that later becomes expensive system configuration. Paper Process in Digital Clothing The most common automation error is simple. An organization takes a paper process and makes it elec- tronic without changing the logic of the work. In the old process, a per- son filled out a form, collected signa - tures, emailed attachments, waited for review, corrected mistakes, and saved a copy. In the new process, a person fills out a screen, routes it for electronic signatures, uploads attach- ments, waits for review, corrects er- rors, and saves a copy in the system. That is not transformation. It is paper process in digital clothing. The Ford accounts payable exam - ple in Hammer and Champy’s 1993 book still matters because Ford did not merely automate invoice match- ing. It removed the invoice from the process. The old approach matched purchase orders, receiving docu- ments, and invoices. The redesigned process used an online database and receiving confirmation to trigger pay - ment, cutting mismatches and staff - ing needs in the function where Ford applied it. The lesson is not to copy Ford. The lesson is that serious reen-
Missions change, statutes change, budgets change, threats change, and leaders inherit structures that no longer fit the work. But reorganization becomes a bad habit when it is used as a substitute for understanding how the work gets done.
gineering changes the work, not just the tool. Department of War organizations should apply the same skepticism to their own paper-era habits. Is the signature required by law or by custom? Is the review adding con- trol or simply adding queue time? Is the spreadsheet an official re- cord, a workaround, or a symptom of poor data trust? Is the local report needed for a decision, or does it ex - ist because the old system could not answer a question? These are not software questions first. They are Weak business process reengi- neering shows up later as over-cus- tomization. A commercial system comes with standard workflows, data structures, controls, reports, and in- tegration patterns. The organization then asks the vendor or integrator to bend the system around local prac- tices. Some customization is unavoid- able in government. Statutes, appro- priations law, security, auditability, mission risk, and policy constraints matter. But not every preference is a requirement. Not every local varia- tion is mission essential. business questions. The Cost of Weak Reengineering The cost compounds quickly. Cus- tom code must be designed, tested, secured, and maintained. Unique in- terfaces must be monitored. Custom reports must be reconciled. Modified workflows must be retested after up - grades. Security patches are becom- ing more complicated because local changes can affect configured logic. Training gets harder because users are not learning the product; they are
learning a local variant. Future mod- ernization is getting more expensive because the organization has built a custom fence around itself. Poor reengineering also drives re- quirements churn. When leaders have not agreed on the future process, the requirements document keeps mov- ing. Every stakeholder discovers an- other must-have, another exception, another local report, or another ap- proval path. Changes after solicitation can also increase acquisition risk and erode confidence in the procurement process. If the organization cannot agree on the work before it buys the tool, it should not expect the tool to settle the argument afterward. Perfection is another trap. Insisting that a product satisfy every local pref- erence can make an otherwise afford - able solution unaffordable. Leaders should separate must-have require- ments from nice-to-have features and be skeptical when users demand that the new system look exactly like the old form. The more the screen must resemble yesterday’s paperwork, the more likely the organization is paving a cow path. The same caution applies to prod- uct selection and implementation. New or unproven tools deserve care- ful reference checks. Vendor assur- ances are not enough. Acquisition teams should speak with comparable users, confirm that the product per - forms as advertised, and understand how much customization those us- ers require. They should also invest in experienced project management and change management. A business system implementation is not a side assignment for whoever has spare
JULY – AUGUST 2026 | DEFENSE ACQUISITION MAGAZINE 21
Made with FlippingBook - Online Brochure Maker