ROI Case File No.445 'The June Deadline and Five Separate Stages'
The June Deadline and Five Separate Stages
Chapter 1: Five Departments Moving in Five Directions
"Accounting wants to replace the accounting system. HR wants to replace the payroll system. Procurement wants to bring in its own system. The managing director overseeing management accounting yells about slow output every month. And I have a deadline in June."
Ryo Nakamura, Systems Director at Globex Corporation, held up five fingers as he spoke — each pointing in a different direction.
"The maintenance contract for our SmileAccounting system expires at the end of June," Nakamura continued. "We'd like to use this as an opportunity to migrate accounting, payroll, and HR onto an integrated ERP. But the departments won't stand down. Accounting says 'we'll choose the system that works best for us,' HR says 'we absolutely cannot change our payroll calculation settings,' and Procurement says 'we're already getting quotes for a separate system.'"
"Is management accounting a separate issue?" I confirmed.
"Yes. After month-end close, it takes two days for the management accounting report to come out. The executives want it the next day. Our current system's architecture can't solve that — even switching ERP might not fix it."
"So," Claude summarized, "within a single engagement, there are five distinct problems and five distinct stakeholders with conflicting interests."
Nakamura nodded heavily. "If we proceed as-is, every department launches its own system and connectivity collapses entirely. But if we force everyone into one ERP, we ignore someone's requirements. Either way, we lose."
Chapter 2: Actors and Props for Each Stage
"This case calls for Scene-Cast Theory."
Gemini drew a wide horizontal table on the whiteboard, with "Scene" on the vertical axis and "Actor (protagonist)," "Object (prop)," and "Action (operation)" across the top.
"Scene-Cast Theory," I began, "is a framework that breaks down business operations into units called 'scenes' and assigns the optimal combination of actors (people) and objects (systems and tools) to each scene. Rather than trying to satisfy everyone with a single large system, the idea is to cast the right players for each scene."
"The reason five departments' requirements are colliding," Claude continued, "is that everyone is trying to stand on the same stage. Split the scenes, and the optimal cast for each scene comes into view."
Gemini began filling in the table.
[Scene 1: Monthly accounting close] Actor: Finance department. Object: Core accounting ERP module. Requirements: accuracy of journal entries and audit compliance. Standard features with no customization needed.
[Scene 2: Payroll and HR management] Actor: HR department. Object: Payroll calculation engine (ERP built-in or dedicated linked module). Requirements: reproduction of complex payroll rules. Here, we honor HR's "absolutely cannot change" position — the ability to port current settings becomes a mandatory vendor selection criterion.
[Scene 3: Procurement management] Actor: Procurement department. Object: Dedicated procurement system (external to ERP). Requirements: flow management from purchase orders to payment. Verify whether the system Procurement is already quoting can connect to the accounting ERP via API.
[Scene 4: Management accounting reports] Actor: Executives and business planning. Object: BI tool (data extraction and visualization). Requirements: output by the day after month-end close. This is not an ERP problem — it is a data pipeline problem. Analyze the data structure with Strategic ROI Intelligence and design auto-aggregation via BI tool as a separate initiative.
[Scene 5: Inter-system integration] Actor: IT department. Object: API gateway. Requirements: accounting, payroll, procurement, and BI all referencing the same source data. Even with separate scenes, the "master copy" of the data is unified.
"Breaking into five scenes," I summarized, "reveals that there's no need to push all departments into one ERP. The shortest path to meeting the June deadline is a three-tier structure: ERP for core accounting and payroll, an external procurement system linked via API, and a BI tool to solve management accounting separately."
Chapter 3: Counting Down to June
Nakamura studied the table, his expression softening slightly.
"When departments were fighting, it felt tangled. Breaking it into scenes, it clears up. So I can allow Procurement's separate system as long as the integration specs align?"
"Exactly," I confirmed. "The core insight of Scene-Cast Theory is the shift from 'unification is the goal' to 'integration is the goal.' They don't have to stand on the same stage. The one thing you cannot compromise on is the corridor connecting the stages — data standardization and API design."
"To reverse-engineer the June timeline," Gemini proposed, "there are three things to do right now. First, complete ERP vendor selection by the end of April. Second, confirm API specifications with the procurement vendor by end of March. Third, start the BI tool design for management accounting in parallel. Running ERP migration and management accounting improvement as separate projects means one's delays don't threaten the other."
"For the conversation with HR," Claude suggested, "make 'the payroll calculation settings will not change' a written commitment — put it explicitly in the vendor evaluation criteria. Add 'portability of current payroll settings' as a required line item and make vendors demonstrate it. That resolves HR's concern."
Nakamura stood up. "Tomorrow, I'm showing these five scenes to each department head. If everyone realizes they've been fighting on separate stages all along, the conversation might finally shift."
Chapter 4: The Order the Curtain Rises
After he left, Claude said quietly: "Trying to fit everyone into one system was what created the situation where no one would be satisfied."
"That's right," I answered. "Integration is a means, not an end. What Scene-Cast Theory teaches is that complex requirements can be broken down and assigned the optimal cast. Even if the stages are separate, the story connects as one."
Outside, spring sunlight was beginning to stream through the windows. Three months to June.
Eight months later, a report arrived from Nakamura.
ERP migration was completed before the June maintenance expiration. Payroll settings were ported one hundred percent successfully — no pushback from HR. The procurement system was connected to the accounting ERP via API, automating the monthly journal import.
The management accounting report delay was solved via BI tool, achieving next-day output. Executive complaints stopped.
Nakamura wrote: "Separating the scenes made it possible for each department head to hear it as a conversation about 'their stage.' What had been invisible when everyone was in the same room arguing over the same system became clear when we spoke scene by scene. Scene-Cast Theory isn't a system design tool — it's a language for moving people."
Five stages became one story.
"The failures of complex system integrations don't come from technical limitations — they come from a lack of design philosophy. What Scene-Cast Theory asks is: who is using this tool, and for what purpose? Rather than forcing everyone into one system, break the scenes and assign the optimal cast. The goal of integration is unified data, not unified systems. This distinction is what makes a June deadline achievable without leaving anyone behind."
Related Files
Tools Used
- Strategic ROI Intelligence — Data structure analysis and management accounting pipeline design support
