HubSpot–SAP Integration Case Study: A Bounded Interface for a Regulated Manufacturer

Summary

Marden Precision manufactures machined components for aerospace and medical customers, at 340 active accounts and an average order value of $74,000. SAP ECC holds the operating record. Its change window is quarterly, its schema is governed by a validation regime, and any modification requires documented testing.

The engagement built a read-only interface between SAP and HubSpot that required no SAP schema change, no new custom table and no modification inside the change window. Sales access to open order status moved from a request-and-wait cycle averaging 1.8 days to a live read, order status enquiries to customer service fell from 210 a month to 34, and quote accuracy against final invoice improved from a variance of 9 percent to 1.5 percent.

Background: A Governed System and an Ungoverned Question

SAP was doing its job. Its change control existed because a validated manufacturing environment requires it, and every attempt to describe the integration as a data problem ran into that fact.

The commercial question was ordinary. A customer asks when their order ships. A seller has no visibility, so they email planning. Planning answers within a day or two, by which point the customer has often called again.

Sia and Soh (2007) classify the misalignments that arise when a package meets an organisation, separating those that stem from the package's own design from those that stem from the regulatory and institutional setting the adopting firm sits in. This was the second kind. Nothing about SAP was wrong; the constraint came from the validation regime around it, and no amount of integration design removes that.

The Audit

Four weeks, running against SAP read access, the HubSpot portal and six months of service tickets.

Enquiry volume. 210 order-status enquiries a month reached customer service, of which 164 were answerable from data SAP already held.

Latency. Median time from a seller's question to an answer was 1.8 days, with a long tail past a week where planning was in a close period.

Quote variance. Quoted price differed from final invoice by a median 9 percent, driven by material surcharges applied in SAP after quotation.

Custody. No agreement existed on where SAP data could come to rest. Two prior integration attempts had stalled at this question rather than at a technical one.

Custody Before Capability

The decision that unblocked the project was where the data would live, taken before any endpoint was discussed.

SAP data would not be copied into HubSpot's database as a mirror. A bounded set of fields would be read on demand and cached for a stated interval inside the client's own cloud tenancy, with the cache holding no material specification, no pricing formula and no personal data beyond a contact name already present in HubSpot. Soh and Sia (2004) found that a gap between a package's assumptions and an organisation's structure can be closed only by changing the organisation, changing the package, or building at the boundary between them. Where the package is under validation, the third option may be the only one available, and naming it as such is what turned a stalled conversation into a scope.

This is the argument Umble, Haft, and Umble (2003) make when they catalogue what determines whether an enterprise-system implementation succeeds: data accuracy, executive involvement, training and sustained governance appear more reliably than any technical variable. Custody is the governance question asked early rather than discovered at a security review.

The Build

Nine weeks, four phases, using SAP OData services already exposed for an existing reporting tool, an Azure Function App and cache in the client's tenancy, and a private HubSpot app.

Phase one, contract. The fields crossing the boundary were agreed in writing with the SAP team and the quality function: order number, line status, promised date, confirmed date, shipped quantity and surcharge code. Nothing else. The list has not changed since.

Phase two, read path. The Function App queries the existing OData services, requiring no new SAP object. Responses are cached for fifteen minutes, which is shorter than the planning cycle and long enough that a seller refreshing a record repeatedly does not generate load inside SAP.

Phase three, surface. Order status appears on the HubSpot company record as a read-only table. It is not a property, because a property would be writable and would eventually be written to.

Phase four, surcharge visibility. The surcharge code is surfaced at quote time with its current rate, so a seller quoting against volatile material sees what will be applied rather than discovering it on the invoice.

Outcomes

Enquiry volume. 210 a month before, 34 after, a reduction of 84 percent. The residual concerns exceptions rather than status.

Answer latency. 1.8 days before, live after. The comparison is imperfect because the question is no longer asked in the same form.

Quote variance. Median 9 percent before, 1.5 percent after, achieved by surfacing the surcharge rather than by changing how anything is priced.

SAP change requests. Zero raised for the life of the project, which was the constraint the design existed to respect.

Load. Peak query rate against SAP held under 4 requests a second, well inside the ceiling agreed with the SAP team, with the cache absorbing roughly 88 percent of reads.

Service time. Customer service time on status enquiries fell by an estimated 26 hours a month.

What Resisted

Caching resisted, for a reason that took a fortnight to surface. Fifteen minutes is acceptable for order status and unacceptable for a promised date during expedite negotiation, when planning may revise a date several times in an hour.

The mechanism was a manual refresh control on the record, which bypasses the cache for that order alone. It is deliberately not automatic: an automatic bypass under load would have produced exactly the query volume the cache was agreed to prevent.

The second difficulty was that a read-only surface disappoints. Sellers asked to update the promised date directly, and the answer was no, because SAP owns it and a write path would have reopened the change-control conversation the project was built to avoid. Karimi, Somers, and Bhattacherjee (2007) found that a deployment becomes a capability only where its outputs enter the working routine of the people the process runs through, and the routine that had to change was the escalation path rather than the record.

Limits

This does not prove a read-only interface is sufficient in general. Marden's commercial process does not require sales to change anything in SAP, and a business where sales legitimately amends orders would find this design obstructive rather than safe.

The approach also depended on OData services already existing for another purpose. A firm without them would face the exposure work first, and that work sits inside the change window this design was built to avoid, which would materially alter the sequence and the cost.

Figures come from the client's service-desk records and SAP query logs. The enquiry-volume comparison spans a period in which order volume rose 7 percent, and no adjustment has been made for that.

Conclusion

The integration succeeded because the first question asked was not how to connect the systems but what the validated system would not be asked to do. The technical work followed from that answer and was unremarkable.

The general form is that a governed system is a constraint to design around rather than an obstacle to argue with. Two prior attempts here failed at the custody question, and neither failed for a technical reason.

References

Karimi, Jahangir, Toni M. Somers, and Anol Bhattacherjee. 2007. "The Role of Information Systems Resources in ERP Capability Building and Business Process Outcomes." Journal of Management Information Systems 24 (2): 221–260. https://doi.org/10.2753/MIS0742-1222240209

Sia, Siew Kien, and Christina Soh. 2007. "An Assessment of Package–Organisation Misalignment: Institutional and Ontological Structures." European Journal of Information Systems 16 (5): 568–583. https://doi.org/10.1057/palgrave.ejis.3000700

Soh, Christina, and Siew Kien Sia. 2004. "An Institutional Perspective on Sources of ERP Package–Organisation Misalignments." Journal of Strategic Information Systems 13 (4): 375–397. https://doi.org/10.1016/j.jsis.2004.11.001

Umble, Elisabeth J., Ronald R. Haft, and M. Michael Umble. 2003. "Enterprise Resource Planning: Implementation Procedures and Critical Success Factors." European Journal of Operational Research 146 (2): 241–257. https://doi.org/10.1016/S0377-2217(02)00547-7

Wand, Yair, and Richard Y. Wang. 1996. "Anchoring Data Quality Dimensions in Ontological Foundations." Communications of the ACM 39 (11): 86–95. https://doi.org/10.1145/240455.240479

Conflict of Interest

RevOps HQ is a HubSpot Solutions Partner and was engaged and paid by the client described.

Acknowledgments

Prepared by RevOps HQ.