[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$flq9GHS8wV-y1mEase9phc88SOtnJAmtlyhqtx-bU43w":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":27,"hasDownload":28,"fileName":29,"youtubeId":30,"domainCrumb":31,"clusterCrumb":34},"404","40CEFD63-759E-5C4B-98B0-CC5372E6BC23","E84414AB-F15F-2145-B6FE-C1332D0FD983","CBFED956-BC0E-8645-B0B5-A6E6F47D1595","article","how-to-build-operational-dashboards-that-people-actually-use","How to build operational dashboards that people actually use","Most operational dashboards get built once and ignored within weeks. Here's how to design dashboards your team actually opens every day.","You've seen this before: a dashboard project kicks off with excitement, someone spends three weeks wiring it up, it gets demoed in a management meeting to nods of approval — and six weeks later nobody has opened it since. The warehouse manager still walks the floor and counts pallets himself. The sales director still asks their assistant to email a weekly Excel summary. The dashboard sits there, technically live, functionally dead.\n\nThis isn't a data problem. It's a design and adoption problem, and it's fixable. Here's what actually makes an operational dashboard something your team opens every morning instead of something they were told to use once.\n\n## Why do so many dashboards get ignored after the first month?\n\nIn almost every case we've seen, it comes down to one of four causes:\n\n1. **The dashboard answers a question nobody is asking.** It was built around data that was easy to pull, not around a decision someone actually needs to make.\n2. **It's too slow or too cluttered.** If a warehouse supervisor has to click through three filters and wait eight seconds for a chart to render, they'll go back to walking the floor.\n3. **The numbers don't match what people already know.** The moment a planner spots a stock figure that contradicts what they saw with their own eyes ten minutes ago, they stop trusting the whole screen — permanently.\n4. **Nobody owns it.** No one is responsible for keeping the underlying data clean, so within a quarter the dashboard is quietly wrong and everyone knows it except the person who built it.\n\nFix these four and adoption stops being a battle.\n\n## What question should every dashboard actually answer?\n\nBefore anyone touches a charting tool, write down one sentence: *\"This dashboard exists so that [role] can decide [decision] without asking [person].\"*\n\nFor example: \"This dashboard exists so that the production planner can decide which machine to prioritize tomorrow morning, without calling the shift leader.\" That sentence tells you exactly which five numbers matter — open orders per machine, current downtime, material availability, due dates, and operator availability — and, just as importantly, everything else you can leave out.\n\nA dashboard that tries to serve everyone serves no one. The finance director's cash-flow view and the warehouse team's pick-rate view should almost never be the same screen.\n\n## How do you pick the right metrics without drowning people in numbers?\n\nA useful rule from real deployments: if a metric doesn't change someone's next action, it doesn't belong on the main screen. Move it to a drill-down.\n\nConcretely:\n\n- **Start from the decision, not the database.** List the 3-5 decisions the role makes daily or weekly, then work backward to the data those decisions need.\n- **Separate \"monitor\" metrics from \"act\" metrics.** A late-shipment count is an act metric — it should be red, bold, and clickable. Total shipments this year is a monitor metric — fine as a small footer number, not the hero of the screen.\n- **Cap the main view at 5-7 tiles.** Anything beyond that and people start scanning instead of reading, which defeats the purpose.\n- **Show trend, not just snapshot.** \"12 late orders\" means little on its own. \"12 late orders, up from 4 last week\" tells someone whether to worry.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F230?w=700&f=webp\" alt=\"five dashboard tiles feeding one clear daily decision\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n## How fast does a dashboard actually need to load?\n\nFaster than people expect, and definitely faster than a report. If someone has to wait for a dashboard the way they'd wait for a monthly report to generate, they mentally file it under \"reports\" — something you check occasionally, not something you glance at constantly.\n\nThe practical target we use: under 2 seconds for the main view, on the device the person will actually use it on. That last part matters — a dashboard that's fast on a developer's laptop but crawls on the warehouse tablet over Wi-Fi will get abandoned by the people who need it most on the floor.\n\nThis is where a lot of dashboard projects quietly fail: they're built on live queries against a production ERP database, and every refresh hammers tables that were never indexed for that kind of read pattern. The fix is usually architectural — a lightweight reporting layer, cached aggregates that refresh every few minutes instead of live joins, or a dedicated summary table that gets updated on a schedule. This kind of separation between operational data and reporting data is one of the core ideas behind building a genuinely [connected digital operating environment](https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-create-a-connected-digital-operating-environment) rather than a patchwork of screens bolted onto whatever system happens to hold the data today.\n\n## How do you make sure people trust the numbers?\n\nTrust breaks in specific, avoidable ways:\n\n- **Timestamp everything.** \"Last updated 3 minutes ago\" next to a figure does more for trust than any amount of polish. If people can't tell whether they're looking at live data or last night's batch, they'll assume the worst.\n- **Match definitions with the people who'll challenge you.** If finance defines \"overdue invoice\" as 30+ days and the dashboard uses 14+ days, you'll get a heated meeting instead of adoption. Sit down with the actual users and agree on definitions before you build anything.\n- **Let people drill into the source.** A single summary number with no way to see the underlying records invites suspicion. A clickable tile that opens the five actual late orders behind that \"12\" builds confidence fast.\n- **Reconcile publicly once.** Pick one week, sit with the skeptical user, and walk through the dashboard number against their manual count line by line. Once they've seen it match, they stop double-checking every day.\n\n## Who should be responsible for a dashboard after launch?\n\nEvery dashboard needs a named owner — not a department, a person — responsible for two things: the accuracy of the underlying data feeding it, and reviewing whether the metrics still match how the business actually operates. Businesses change: a new warehouse location gets added, a product line gets discontinued, a KPI target shifts from quarterly to monthly. A dashboard nobody owns quietly drifts out of sync with reality, and the first person to notice is usually the frustrated end user, not the IT team.\n\nA light but effective ownership model:\n\n- Owner reviews the dashboard monthly against actual operations.\n- Any change to underlying data structures (new order status, renamed field, new location) triggers a dashboard check, not an afterthought.\n- Users have one clear channel to flag \"this number looks wrong\" — and someone actually responds within a day, not a sprint cycle.\n\n## What role can AI play in an operational dashboard?\n\nAI is genuinely useful here, but not as a chatbot bolted onto a screen for novelty's sake. The practical uses we've seen work:\n\n- **Anomaly flagging.** Instead of a static red\u002Fgreen threshold, a model that learns normal seasonal patterns can flag \"this is unusual for a Tuesday in March\" rather than firing false alarms every Monday morning.\n- **Natural-language summaries.** A short AI-generated sentence at the top of the dashboard — \"Late orders are up 40% this week, mostly driven by Supplier X\" — gets read by executives who would otherwise skim past six tiles of numbers.\n- **Plain-language querying.** Letting a manager type \"which customers had more returns than usual this month\" and get a filtered view, instead of asking IT to build a new report every time a new question comes up.\n\nThe trade-off: AI features need clean, well-modeled underlying data to be trustworthy. Bolting an AI summary onto messy, inconsistent source data just produces confident-sounding wrong answers — arguably worse than no summary at all.\n\n## What does a good rollout process actually look like?\n\n1. **Interview the actual users, not their managers.** The person who'll open the dashboard daily knows what they need far better than the person who requested it.\n2. **Build a rough version fast — in days, not months.** A clickable prototype with real (even partial) data gets far more honest feedback than a polished mockup with fake numbers.\n3. **Test it on the real device, in the real environment.** A dashboard that looks great on a 27-inch monitor can be unusable on a shop-floor tablet in bright light.\n4. **Run a 2-3 week shadow period.** Keep the old manual process running alongside the new dashboard, and watch — don't ask — whether people start relying on the new one.\n5. **Retire the old process explicitly.** If the spreadsheet or the manual walk-around never officially gets cancelled, most teams quietly keep doing both forever, and the dashboard investment never pays off.\n\n## Quick checklist before you call a dashboard \"done\"\n\n- [ ] One sentence exists defining exactly which decision this dashboard supports, and for whom\n- [ ] Main view has 5-7 tiles max, each tied to an action\n- [ ] Loads in under 2 seconds on the actual device people will use\n- [ ] Shows a trend, not just a snapshot, for key metrics\n- [ ] Every number has a visible \"last updated\" timestamp\n- [ ] Definitions are agreed with the people most likely to challenge them\n- [ ] Numbers drill down to source records\n- [ ] A named person owns data accuracy and monthly review\n- [ ] Old manual process has been formally retired\n\n## FAQ\n\n**How many dashboards should one company have?**\nFewer than you think. It's almost always better to have three sharply-focused dashboards, each built for one role and one decision, than one giant dashboard trying to serve the whole company.\n\n**Should dashboards be built in the same system as our ERP\u002FCRM?**\nNot necessarily live against it. Pulling dashboard queries directly from a transactional database can slow down the core system and produce inconsistent numbers during heavy write activity. A separate reporting layer or scheduled aggregation, even inside the same platform, is usually more stable.\n\n**Can a dashboard replace a report?**\nFor daily operational decisions, yes — that's the point. For formal monthly or statutory reporting, keep the two separate; reports need auditability and a fixed point in time, while dashboards need to stay live.\n\n**What's the single biggest reason dashboards fail?**\nBuilding around available data instead of around a real decision someone needs to make. Everything else on this list is downstream of getting that first step wrong.\n\nIf your team already has dashboards that quietly stopped being opened months ago, the underlying issue is rarely the charting tool — it's usually the data model, the update speed, or the missing owner behind it. Loggix builds custom FileMaker and web-based operational dashboards designed around one specific decision at a time, connects them to your existing ERP, CRM, or production systems through proper API integrations rather than fragile exports, and can layer in AI summaries or anomaly detection once the underlying data is solid enough to support it. If you're not sure where your current setup breaks down, that's exactly the kind of question a short consultancy session can answer before you invest in building anything new.","\u003Cp>You've seen this before: a dashboard project kicks off with excitement, someone spends three weeks wiring it up, it gets demoed in a management meeting to nods of approval — and six weeks later nobody has opened it since. The warehouse manager still walks the floor and counts pallets himself. The sales director still asks their assistant to email a weekly Excel summary. The dashboard sits there, technically live, functionally dead.\u003C\u002Fp>\n\u003Cp>This isn't a data problem. It's a design and adoption problem, and it's fixable. Here's what actually makes an operational dashboard something your team opens every morning instead of something they were told to use once.\u003C\u002Fp>\n\u003Ch2>Why do so many dashboards get ignored after the first month?\u003C\u002Fh2>\n\u003Cp>In almost every case we've seen, it comes down to one of four causes:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>The dashboard answers a question nobody is asking.\u003C\u002Fstrong> It was built around data that was easy to pull, not around a decision someone actually needs to make.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>It's too slow or too cluttered.\u003C\u002Fstrong> If a warehouse supervisor has to click through three filters and wait eight seconds for a chart to render, they'll go back to walking the floor.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>The numbers don't match what people already know.\u003C\u002Fstrong> The moment a planner spots a stock figure that contradicts what they saw with their own eyes ten minutes ago, they stop trusting the whole screen — permanently.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Nobody owns it.\u003C\u002Fstrong> No one is responsible for keeping the underlying data clean, so within a quarter the dashboard is quietly wrong and everyone knows it except the person who built it.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Fix these four and adoption stops being a battle.\u003C\u002Fp>\n\u003Ch2>What question should every dashboard actually answer?\u003C\u002Fh2>\n\u003Cp>Before anyone touches a charting tool, write down one sentence: \u003Cem>"This dashboard exists so that [role] can decide [decision] without asking [person]."\u003C\u002Fem>\u003C\u002Fp>\n\u003Cp>For example: "This dashboard exists so that the production planner can decide which machine to prioritize tomorrow morning, without calling the shift leader." That sentence tells you exactly which five numbers matter — open orders per machine, current downtime, material availability, due dates, and operator availability — and, just as importantly, everything else you can leave out.\u003C\u002Fp>\n\u003Cp>A dashboard that tries to serve everyone serves no one. The finance director's cash-flow view and the warehouse team's pick-rate view should almost never be the same screen.\u003C\u002Fp>\n\u003Ch2>How do you pick the right metrics without drowning people in numbers?\u003C\u002Fh2>\n\u003Cp>A useful rule from real deployments: if a metric doesn't change someone's next action, it doesn't belong on the main screen. Move it to a drill-down.\u003C\u002Fp>\n\u003Cp>Concretely:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Start from the decision, not the database.\u003C\u002Fstrong> List the 3-5 decisions the role makes daily or weekly, then work backward to the data those decisions need.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Separate "monitor" metrics from "act" metrics.\u003C\u002Fstrong> A late-shipment count is an act metric — it should be red, bold, and clickable. Total shipments this year is a monitor metric — fine as a small footer number, not the hero of the screen.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Cap the main view at 5-7 tiles.\u003C\u002Fstrong> Anything beyond that and people start scanning instead of reading, which defeats the purpose.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Show trend, not just snapshot.\u003C\u002Fstrong> "12 late orders" means little on its own. "12 late orders, up from 4 last week" tells someone whether to worry.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F230?w=700&f=webp\" alt=\"five dashboard tiles feeding one clear daily decision\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Ch2>How fast does a dashboard actually need to load?\u003C\u002Fh2>\n\u003Cp>Faster than people expect, and definitely faster than a report. If someone has to wait for a dashboard the way they'd wait for a monthly report to generate, they mentally file it under "reports" — something you check occasionally, not something you glance at constantly.\u003C\u002Fp>\n\u003Cp>The practical target we use: under 2 seconds for the main view, on the device the person will actually use it on. That last part matters — a dashboard that's fast on a developer's laptop but crawls on the warehouse tablet over Wi-Fi will get abandoned by the people who need it most on the floor.\u003C\u002Fp>\n\u003Cp>This is where a lot of dashboard projects quietly fail: they're built on live queries against a production ERP database, and every refresh hammers tables that were never indexed for that kind of read pattern. The fix is usually architectural — a lightweight reporting layer, cached aggregates that refresh every few minutes instead of live joins, or a dedicated summary table that gets updated on a schedule. This kind of separation between operational data and reporting data is one of the core ideas behind building a genuinely \u003Ca href=\"https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-create-a-connected-digital-operating-environment\">connected digital operating environment\u003C\u002Fa> rather than a patchwork of screens bolted onto whatever system happens to hold the data today.\u003C\u002Fp>\n\u003Ch2>How do you make sure people trust the numbers?\u003C\u002Fh2>\n\u003Cp>Trust breaks in specific, avoidable ways:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Timestamp everything.\u003C\u002Fstrong> "Last updated 3 minutes ago" next to a figure does more for trust than any amount of polish. If people can't tell whether they're looking at live data or last night's batch, they'll assume the worst.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Match definitions with the people who'll challenge you.\u003C\u002Fstrong> If finance defines "overdue invoice" as 30+ days and the dashboard uses 14+ days, you'll get a heated meeting instead of adoption. Sit down with the actual users and agree on definitions before you build anything.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Let people drill into the source.\u003C\u002Fstrong> A single summary number with no way to see the underlying records invites suspicion. A clickable tile that opens the five actual late orders behind that "12" builds confidence fast.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Reconcile publicly once.\u003C\u002Fstrong> Pick one week, sit with the skeptical user, and walk through the dashboard number against their manual count line by line. Once they've seen it match, they stop double-checking every day.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Who should be responsible for a dashboard after launch?\u003C\u002Fh2>\n\u003Cp>Every dashboard needs a named owner — not a department, a person — responsible for two things: the accuracy of the underlying data feeding it, and reviewing whether the metrics still match how the business actually operates. Businesses change: a new warehouse location gets added, a product line gets discontinued, a KPI target shifts from quarterly to monthly. A dashboard nobody owns quietly drifts out of sync with reality, and the first person to notice is usually the frustrated end user, not the IT team.\u003C\u002Fp>\n\u003Cp>A light but effective ownership model:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Owner reviews the dashboard monthly against actual operations.\u003C\u002Fli>\n\u003Cli>Any change to underlying data structures (new order status, renamed field, new location) triggers a dashboard check, not an afterthought.\u003C\u002Fli>\n\u003Cli>Users have one clear channel to flag "this number looks wrong" — and someone actually responds within a day, not a sprint cycle.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>What role can AI play in an operational dashboard?\u003C\u002Fh2>\n\u003Cp>AI is genuinely useful here, but not as a chatbot bolted onto a screen for novelty's sake. The practical uses we've seen work:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Anomaly flagging.\u003C\u002Fstrong> Instead of a static red\u002Fgreen threshold, a model that learns normal seasonal patterns can flag "this is unusual for a Tuesday in March" rather than firing false alarms every Monday morning.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Natural-language summaries.\u003C\u002Fstrong> A short AI-generated sentence at the top of the dashboard — "Late orders are up 40% this week, mostly driven by Supplier X" — gets read by executives who would otherwise skim past six tiles of numbers.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Plain-language querying.\u003C\u002Fstrong> Letting a manager type "which customers had more returns than usual this month" and get a filtered view, instead of asking IT to build a new report every time a new question comes up.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>The trade-off: AI features need clean, well-modeled underlying data to be trustworthy. Bolting an AI summary onto messy, inconsistent source data just produces confident-sounding wrong answers — arguably worse than no summary at all.\u003C\u002Fp>\n\u003Ch2>What does a good rollout process actually look like?\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Cstrong>Interview the actual users, not their managers.\u003C\u002Fstrong> The person who'll open the dashboard daily knows what they need far better than the person who requested it.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Build a rough version fast — in days, not months.\u003C\u002Fstrong> A clickable prototype with real (even partial) data gets far more honest feedback than a polished mockup with fake numbers.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Test it on the real device, in the real environment.\u003C\u002Fstrong> A dashboard that looks great on a 27-inch monitor can be unusable on a shop-floor tablet in bright light.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Run a 2-3 week shadow period.\u003C\u002Fstrong> Keep the old manual process running alongside the new dashboard, and watch — don't ask — whether people start relying on the new one.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Retire the old process explicitly.\u003C\u002Fstrong> If the spreadsheet or the manual walk-around never officially gets cancelled, most teams quietly keep doing both forever, and the dashboard investment never pays off.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>Quick checklist before you call a dashboard "done"\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> One sentence exists defining exactly which decision this dashboard supports, and for whom\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Main view has 5-7 tiles max, each tied to an action\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Loads in under 2 seconds on the actual device people will use\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Shows a trend, not just a snapshot, for key metrics\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Every number has a visible "last updated" timestamp\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Definitions are agreed with the people most likely to challenge them\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Numbers drill down to source records\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> A named person owns data accuracy and monthly review\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Old manual process has been formally retired\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>How many dashboards should one company have?\u003C\u002Fstrong>\nFewer than you think. It's almost always better to have three sharply-focused dashboards, each built for one role and one decision, than one giant dashboard trying to serve the whole company.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Should dashboards be built in the same system as our ERP\u002FCRM?\u003C\u002Fstrong>\nNot necessarily live against it. Pulling dashboard queries directly from a transactional database can slow down the core system and produce inconsistent numbers during heavy write activity. A separate reporting layer or scheduled aggregation, even inside the same platform, is usually more stable.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Can a dashboard replace a report?\u003C\u002Fstrong>\nFor daily operational decisions, yes — that's the point. For formal monthly or statutory reporting, keep the two separate; reports need auditability and a fixed point in time, while dashboards need to stay live.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>What's the single biggest reason dashboards fail?\u003C\u002Fstrong>\nBuilding around available data instead of around a real decision someone needs to make. Everything else on this list is downstream of getting that first step wrong.\u003C\u002Fp>\n\u003Cp>If your team already has dashboards that quietly stopped being opened months ago, the underlying issue is rarely the charting tool — it's usually the data model, the update speed, or the missing owner behind it. Loggix builds custom FileMaker and web-based operational dashboards designed around one specific decision at a time, connects them to your existing ERP, CRM, or production systems through proper API integrations rather than fragile exports, and can layer in AI summaries or anomaly detection once the underlying data is solid enough to support it. If you're not sure where your current setup breaks down, that's exactly the kind of question a short consultancy session can answer before you invest in building anything new.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901679000,[19,20,21,22,23,24,25,26],"operational dashboards","FileMaker dashboards","business intelligence","KPI reporting","data visualization","digital operations","AI in dashboards","low-code dashboards","\u002Fapi\u002Fknowledge\u002Fimage\u002F404\u002F?v=7e171c49c2cd",false,"",null,{"title":32,"slug":33},"Digital Operations","digital-operations",{"title":35,"slug":36},"How to create a connected digital operating environment","how-to-create-a-connected-digital-operating-environment"]