Which Applications Join the Shared Picture

A chief operating officer already lives with the applications that run the company. Each application holds facts that people use when they act. The live question is which of those applications should share information into one operational picture. The matching question is which applications should stay on their own. That split is an operating decision. It is not a catalog of products, and it is not a contest among vendors.

The shared picture is the view used to answer how work is moving this week. It is not every screen inside every product. It is a selected set of facts that must sit together so a decision is possible. Orders, inventory positions, cash movement, delivery status, and open work usually belong in that set. Personal drafts, experimental tools, and closed legal files usually do not.

This article is a working brief for that split. An owner, a COO, or an office manager should be able to use it without translating it into another language of planning. Further reading on listing the systems that exist sits at the applications assessment page. The work here is the decision after the list exists. The work is which names join the picture, and which names remain alone.

What the shared picture is for

An operational picture exists so a small group can see the same state of the company at the same time. It exists so a morning question does not require five logins and a hallway search. It exists so yesterday’s exceptions sit next to today’s capacity. It does not exist to replace the applications that do the real work. Those applications still take orders, post invoices, schedule people, and move goods.

The picture answers a short list of operating questions. How much work is in, how much is promised, and how much is blocked. What is late, what is short, and what is waiting on a person or a part. What cash is expected, and what work will consume that cash. If a fact does not change the answer to those questions, it does not earn a place in the picture.

A picture that tries to hold everything becomes another application that no one trusts. People then keep private lists, and the shared view dies. A picture that holds too little forces the COO back into each source system for every meeting. Both failures are common. The cure is a hard split, written down, and used in the same meeting every week.

The picture should display. It should not become a new system of record. When the picture starts accepting edits that never return to the source, the company now has two truths. Two truths will disagree within a month, and the disagreement will show up in front of a customer. Keep the picture as a window. Keep the source as the place where a record is born, changed, and closed.

What sharing information actually changes

Sharing information does not mean giving every person a login to every product. It means selected fields leave their home application on a known path. Those fields land in a place where they can be seen beside fields from other homes. The path can be a scheduled extract, an event, or a controlled query. The path should be named, owned, and reversible.

A feed is not a copy of the whole application. A full copy drifts, and then people argue about which copy is current. A feed should carry only the fields the picture needs. Customer name, order status, promised date, and quantity on hand are typical. Private notes, draft emails, and specialist working files are not typical.

A link is weaker than a feed and stronger than a rumor. A link says the picture shows a key, and a person still opens the source to see the rest. Links are useful when the rest is sensitive or too detailed for a weekly view. Links fail when the meeting needs the detail and no one can open the source in time. Choose a feed when the meeting must act. Choose a link when the meeting must only know where the truth lives.

Sharing also changes who can infer things they could not infer before. Status next to margin next to a person can reveal a story that each system hid on its own. That can be the point of the picture. It can also be a problem if the audience is too wide. Decide the audience before you decide the feed. Do not connect first and restrict later.

Unapproved AI tools and personal AI accounts should not receive a feed from the picture or from the source list. Those places are not operating systems of the company. They are personal habits that create a second, uncontrolled copy. Keep them out of the split entirely. If someone has been pasting operating facts into a personal account, stop that path before you design a shared view.

Which applications belong in the picture

An application belongs in the picture when the COO cannot run the week without seeing its facts next to other facts. The test is operational, not technical. If a missed update in that system would cause a wrong promise, a wrong purchase, or a wrong schedule, it is a candidate. If people already talk about its numbers in the same meeting as other numbers, it is a candidate. If only a specialist uses it for deep work, it is not.

Customer-facing work usually belongs. The system that holds open orders, promises, and delivery exceptions should feed the picture. The system that holds inventory available to promise should feed the picture. The system that holds production or job status should feed the picture when the company makes or serves to a date. Without those, the picture is a story about intention, not about what will actually ship.

Money in motion usually belongs, with care. The application that holds invoices, receipts, and open receivables should feed selected totals and aging, not every private note. The application that holds payables and committed spend should feed what will leave the bank, not the full ledger. The general ledger can stay deeper than the picture. The picture needs cash pressure and working capital movement, not every posting.

People capacity belongs when labor is the constraint. A scheduling application, a time system, or a roster tool should feed who is available and which jobs are covered. It should not feed performance notes, medical details, or pay rates into a wide view. The picture needs hours and coverage. It does not need a personnel file.

A specialty line system belongs when the line is the company. A shop floor system, a clinic schedule, a warehouse system, or a field service tool is often the true clock of the week. If that clock is missing from the picture, the picture will be polite and late. Feed status, backlog, and exceptions. Leave recipes, clinical charts, and engineering files in their home.

Microsoft 365 may feed the picture only for facts that are already operating records. A list of open work in a tracked list can belong. Mailboxes and personal calendars do not belong. Shared mail used as an unofficial order book should be retired from that role rather than connected. The picture should not bless a mailbox as a system of record.

Which applications should stay on their own

An application should stay on their own when combining it would not change an operating move this week. Deep tools for one role often fail this test. Computer aided design, tax workpapers, legal research, and laboratory instruments are examples. People who use them need the full product. The COO needs a status, not the model.

Privileged people data should stay on their own. Payroll details, benefits elections, investigations, and medical leave files do not belong in an operational picture. A headcount total or a coverage flag can belong. The file behind the flag must not. If the only way to share coverage is to share the file, keep the application out and take a verbal exception in the meeting.

Legal, claim, and dispute files should stay on their own. Those records are built for counsel and for a process that is slower than a weekly operating rhythm. Pulling them into a picture trains people to manage legal work as if it were a late shipment. It is not. A count of open matters can be spoken. The contents stay in their home.

Sandbox, trial, and personal paid accounts should stay on their own. They are not company records. Connecting them teaches the picture to trust unfinished experiments. If a trial becomes real, promote it through the same split you use for every other name. Do not let a personal account become a quiet source of operating truth.

Archive and backup stores should stay on their own. They are for recovery and for history, not for this week’s action. Feeding an archive into a picture invites people to treat old snapshots as live. That error is hard to see and easy to act on. Keep archives where they are. Point to them only when a historical question is the actual work.

Duplicate systems should stay out if a better system of record already feeds the picture. Two inventory tools, two customer lists, or two job boards will fight. The picture will average them in someone’s head, which is worse than a known gap. Choose one source for each object. Name the loser as a system that stays on its own until it is retired.

Record, work, and supporting tools

Sort every application into one of three jobs before you talk about feeds. A record system owns an object for the company. A work system is where people do tasks on that object. A supporting tool helps a person think, draft, or calculate, and it does not own the object. Only record systems should feed the picture as truth. Work systems may feed status. Supporting tools should stay on their own.

The customer record should have one home. The item or service record should have one home. The invoice should have one home. The employee record should have one home. If two applications both claim to own the same object, the picture will lie as soon as they diverge. Write the owner beside the object. Do not hope the feed will reconcile a fight that the company has not settled.

Work systems can join as status, not as masters. A board that tracks tasks can say a job is blocked. It should not invent a new customer. A warehouse terminal can say a bin is empty. It should not invent a new item. When a work system has become the unofficial master, admit that in writing. Then either promote it or stop treating its numbers as company truth.

Supporting tools include spreadsheets used for thinking, personal lists, and calculators. They are allowed. They are not sources. If a spreadsheet has become the only place a number exists, it has quietly become a record system. Treat it as one. Give it an owner, a refresh rule, and a decision about the picture. Do not leave it as a private brain that the meeting borrows under stress.

A paid account is a licence to use a product. It is not a reason to connect that product. Plenty of useful licences should remain isolated because their job is narrow. Connection is a second decision. Buy the work you need. Share only the facts the week requires.

Timing, quality, and who may look

Decide how fresh each field must be before you connect anything. Some fields need to move when the event happens. Order promised, job blocked, and inventory short often need that speed. Some fields are safe as a daily extract. Aging, throughput, and hours worked often fit that pace. Some fields should move only on request. Deep cost, private customer history, and exception files often fit that bar.

A slow feed of a fast fact trains people to ignore the picture. They will open the source, and they will be right to do so. A fast feed of a slow fact creates noise. Overnight batch totals that twitch all day are an example. Match the clock of the field to the clock of the decision. Write the clock next to the field name so the meeting knows what it is seeing.

Quality travels with the feed. If the source has duplicate customers, the picture will show duplicate work. If the source has blank promised dates, the picture will show false calm. Clean the object in its home before you share it. If you cannot clean it, share a smaller field set, or keep the application on its own until the home is fit. A pretty picture of dirty records is a management hazard.

Name the audience as a role list, not as a hope that people will be careful. The COO, the owner, and the office manager often need the full operating view. A supervisor may need only the slice for a team or a site. A wide staff view should be rare. If a field would change how you speak in a mixed room, it does not belong in the wide view.

Service areas differ in who is on site and who is remote. The picture should not assume everyone can walk to a specialist. If the only person who can interpret a feed sits in one service area, the feed is fragile. Either teach a second reader or keep that application on its own and bring a spoken exception. Fragility is an operating fact, not a technical footnote.

Further reading on a shared view of numbers in your own account is on the dashboard deployment page. Use that as background on the form a picture can take. The decision in this article is still which applications donate fields, and which do not. Form follows that split. The split does not follow a screen layout.

Contracts, privacy, and informal copies

Some walls are required. A processor agreement, a customer contract, or a professional rule may forbid mixing a class of data with other classes. Clinical, payment, children’s, or legal data often come with such a wall. Read the rule as an operator, not as a hobbyist. If the rule says the data stays in its system, the application stays on its own. Do not invent a clever feed that violates the point of the rule.

Privacy is not only a legal file. It is also the reasonable expectation of staff and customers. A picture that shows who is on leave beside who missed a quota will teach the wrong lesson. A picture that shows a customer’s private note beside a public delay will leak trust. When in doubt, feed a status flag and leave the narrative in the home system.

Informal copies already exist, and they are competing pictures. The unofficial spreadsheet on a laptop, the whiteboard in a room, and the text thread on a phone are all pictures. They exist because the official view is too slow, too wide, or too empty. You will not defeat them by scolding. You will defeat them by making a shared picture that answers the same questions with less effort.

Hunt the informal copies before you add a new feed. Ask the office manager where the real list lives on Sunday night. Ask the owner what they check before a customer call. Those answers name the fields that must join. They also name the applications that can stay alone because no one... no, they name the applications that can stay alone because no one is using them for the week.

If an informal copy is the only honest view, write that down as a failure of the current split. Either promote that copy into a managed record, or replace it with a feed from a real home. Do not connect five applications and leave the Sunday spreadsheet in charge. The picture will then be theatre.

Unapproved AI tools belong in this same bucket of informal copies. They are not listed as company applications, yet they may hold customer text and operating notes. Keep them out of any feed. Treat a personal AI account as a place that should never receive the shared picture. The reader does not need a tour of how those products work. The reader needs them excluded.

When to reopen a join or a stay

Reopen a stay when a spoken exception appears in the meeting on a regular rhythm. A one time exception is information. A regular exception is a field that wants a feed. Write the field, the clock, and the audience, and then decide. Do not reopen the entire application because one field became useful.

Reopen a join when people stop using the field, or when the field causes arguments about meaning. Unused fields are weight. Argued fields are a sign that the home is unclear or the definition drifted. Pause the feed. Fix the home or the definition. Then restore a smaller field set, or move the application back to stay.

Reopen the audience when a new role needs the week in one view, or when a leak has taught you the room was too large. Audience is not a one time choice. It is part of how the company talks. Treat a change in audience as seriously as a change in feed. The facts may stay the same. The harm may not.

Do not reopen the split because a product gained a new button. Product change is not operating change. If the button does not alter a weekly question, the application keeps its current place. Curiosity about new features is a lab matter. The picture is not a lab.

Reopen after a contract change, a new line of work, or a merger of records. Those events change objects, walls, and systems of record. Run the same tests you used the first time. Belonging is earned by the week, not by history. A former join can become a stay. A former stay can become a join.

A calm review once a year in a named year is enough for most companies if the weekly meeting is allowed to raise exceptions. Do not create a festival of reconnection. Do not freeze the list until it is fiction. The standard is a list that still matches how the week is actually run.

The approach page is further reading on how technology management work is sequenced. The FAQ collects common questions about that work. Neither page is a substitute for the split in this brief. Use them if you need context. Use this brief to name which applications share information, and which remain on their own.

A COO who can point to a written join and a written stay can run the meeting without hunting. An owner can disagree with a reason instead of with a feeling. An office manager can refuse a sloppy feed without turning the refusal into a personality fight. That is the whole point of the split. Third Shift Group LLC publishes this as advice for operators who must make that split and live with it.