Brazil operations
What looks like a visibility problem is usually two systems that never met.
One company, two operations, and a gap that somebody crosses by hand every month. Redbeard builds systems for the Brazilian side of that gap, most often for companies headquartered in China, and the design below holds for any headquarters that reads a Brazilian operation from a distance. None of it is cultural, and none of it is solved by asking for more detail in the report.
From headquarters
How the gap actually shows up on your side
You are unlikely to see any of this as a systems problem, because none of it arrives labeled that way. It arrives as a number that does not match, an answer that takes a day, and a person you have learned to write to directly.
- The monthly figures arrive, and when they do not match, the conversation turns to the spreadsheet instead of the operation.
- Finding out where something stands means writing to a person, and it is always the same person.
- An approval you gave two months ago cannot be reconstructed: who asked for it, on what basis, and what happened next.
- Brazilian documents exist because Brazilian law requires them, and none of them sits anywhere you can open.
- A decision waits half a day, because it left at the end of one working day and arrived at the start of another.
- When that one person leaves, the operation leaves with them. It was never written down anywhere.
Scope
Nothing at headquarters gets replaced
This is the first question most people ask, and the answer is short. The work happens on the Brazilian side. Your reporting format is a destination, not an origin, and it does not need to change for any of this to work. You install nothing, migrate nothing, and nobody on your side has to learn a new tool.
The Brazilian side operates in it
Cases, documents, approvals and numbers are created where the work actually happens, in the language the people doing it speak.
Headquarters reads from it
The same state, the same case, the same document, with no local version and no version for you. What you receive stops being a retelling.
Boundary
What gets built here, and what does not
Redbeard is a digital engineering studio. In an operation that spans two countries, that boundary is worth stating plainly, because hiring engineering and expecting advisory ends badly for both sides.
Builds
- One system for the Brazilian operation, readable from both ends, with roles and permissions per side.
- The document attached to the case, with versions, instead of attached to a conversation someone has to go find.
- Every number carrying its origin, currency and date, so the report stops being a reconstruction.
- The decision recorded where it was made: who decided, when, and on what basis.
Does not
- Accounting and tax filing.
- Legal, corporate or immigration advice.
- Contract translation, or negotiating with your Brazilian team.
- Customs clearance and trade intermediation.
- When the problem is one of those, we say which one, and we do not build.
Design decisions
What changes in the design when the two ends are half a day apart
A system for an operation that spans two countries is not a normal system with the labels translated. Three decisions change, and all three are made before the first screen.
Asynchronous by default
Nothing essential can depend on two people being awake at the same time. The system is the source of truth and the conversation is a comment on it, never the other way around. A meeting held to find out where things stand is a symptom that the state is not written down anywhere.
The effect: the operation stops waiting half a day for someone to wake up.
Bilingual only where it changes a decision
Status, document names, units and values come out in Portuguese and English. Free text does not. Translating everything costs maintenance forever and improves no decision, and a field translated halfway is worse than a field in one language, because it looks reliable.
The effect: both ends read the same case without a translator in between.
Every date and time carries its time zone
"Approved on the 12th" is ambiguous between the two ends, and the ambiguity only shows up on the day a deadline is missed. The system stores the instant, and each side reads it in its own zone.
The effect: a deadline stops depending on who is counting.
The first step
The shape of an operation map
The map is not a technology audit. It is your operation handed back in a readable form, with the points where information stops and what each stop costs. The engineering behind it is not new: it is the same that today runs six kinds of system in production, with several companies in one system and data separated per company, documents attached to the case, roles, deadlines and an audit trail. What changes here is the design, not the capability. Below, the shape of the document.
- What headquarters receives today
- A spreadsheet rebuilt by handThree working days of one person, every month. The total drifts from the local system at every change in the exchange rate
- Where the information is born
- The local system, in Portuguese, with Brazilian tax dataBuilt to satisfy the requirement here, never designed to be read from outside
- What headquarters keeps as it is
- The reporting format and the tools around itIt is a destination, not an origin. Nothing on your side is replaced
- What blocks a decision
- Approvals do not live in the caseThey arrive as messages, get acted on, and two months later nobody can reconstruct the basis
- What is not a systems problem
- Who approves an exception was never agreedRecording it faster does not settle it. It stays out of scope until the agreement exists
- First slice proposed
- Generated report and recorded approvalsTogether they remove the monthly retyping and the reconstruction. The rest comes later, if it is still missing
Example written with fictional data to show the shape of the document. A client's operation map is never published, anonymized or otherwise, for the same reason that holds for the process discovery: the shape of an operation identifies more than the company name.
Next step
Describe the operation you currently see only through a report.
A description in plain language is enough: what the Brazilian operation does, what has to reach you, and what crosses by hand today. If the answer is that this is not a software problem, it comes back that way. It is written in the box above.
How a process becomes a system, and how it is hired in stages