The program dashboard is green. The published app is still spinning. PMO status says on track. CDN and API checks returned 200. Protocol tiles for Citrix or AVD look healthy. Consultants and client users are still waiting for SAP, Oracle, Workday, or a custom portal to paint. That is the Deloitte-related response-time problem: program and infra green is not the wait delivery teams feel on screen.
Direct answer: Measure response time for the applications and virtual desktops that matter in Deloitte-led transformations and day-to-day consulting delivery – from what users see on screen (on the glass) – not only from program dashboards, PMO status, CDN or API 200s, or protocol health tiles. Time the interval from a click or key until the expected UI is visible: login-to-usable shell or desktop, published-app or portal ready, key business transaction click-to-ready (for example an SAP, Oracle, or Workday step), and report/export or handoff ready. That interval is click-to-ready – the number a delivery lead, client IT, and help desk can share.
Deloitte is a global network of member firms spanning audit, tax, consulting, advisory, and digital (firm context: Deloitte / Deloitte US). Tevron is not affiliated with Deloitte; Deloitte is a trademark of its respective owners. This article is not about timing Deloitte as a product – it is about timing the enterprise apps and VDI sessions that matter when Deloitte leads or supports a transformation. Sister glass methods: Citrix, RDS, cloud VDI, Epic, Oracle Health / Cerner, and Remedly. Method framing: on-the-glass APM, CitraTest VU, and CitraTest APM.
Why a green program or protocol tile is not “ready”
Transformation programs report milestones, RAID items, and cutover checklists. SaaS and custom portals sit behind HTTPS, CDNs, identity providers, and browsers. Citrix and AVD publish apps and desktops behind ICA/HDX or RDP. Uptime pages, URL checks, API latency, PMO dashboards, and protocol tiles tell you the program is tracking and the service or session broker is up. They are not a stopwatch for “the published app painted,” “the Workday step confirmed,” or “the SAP transaction is usable.”
A Workspace window can stream a spinner, a skeleton portal, a half-hydrated Oracle form, or a toast that never confirms – and still count as a successful launch or HTTP 200. Client-side rendering and heavy ERP transactions sit after the network and broker already said OK. An HTTP generator that hammers login times the front door, not the consulting workflow.
A green program dashboard is useful. It is not the same as “the published app appeared.”
When SAP, Oracle, Workday, or a custom portal runs inside Citrix, Microsoft RDS, AVD, or other cloud VDI, the split doubles: protocol green still is not UI ready. HDX or RDP can stream a spinning shell while the business app is still hydrating. Host CPU and broker tiles do not close a “the app is slow” ticket during a Deloitte-led go-live. Use the Citrix, RDS, and cloud VDI posts above for remoting.
Left stack is what PMO, CDN/API, and remoting health see. Right stack is what consultants and client users wait on. Only the glass stack is response time as a person experiences it in Deloitte-related delivery.
Which steps to time in Deloitte-led work
Write the steps before you pick a tool. Four intervals cover most UX arguments on published apps, portals, and remoted desktops in transformation and consulting delivery:
- Sign-in to usable shell / desktop – from credentials submitted (or SSO return) until a usable Workspace, desktop, or portal chrome is ready – menus, no full-screen spinner. Not “the IdP redirected” or “the broker session started.”
- Published app / portal ready – from launching the published SAP, Oracle, Workday, or custom portal until that app’s home or landing UI is interactive. Not “the icon flashed” or “the process started.”
- Key business transaction – from the click that starts a representative SAP, Oracle, or Workday step (or a custom portal transaction) until that step’s ready state on glass. Pin the ready image for the engagement’s build.
- Report / export / handoff – from the click that starts a report, export, or handoff step until results or confirmation paint – the step that often generates “still waiting” tickets at cutover.
Pin the browser or published-app / Workspace image, display scale, tenant branding, and ready baselines. A timer on a moving theme is a story, not a measurement. When work runs inside Citrix or other VDI, run a logon storm separately from density. Storm stresses login-to-shell; density stresses in-session SAP / Oracle / Workday work on hosts that already have users.
Time it like a script, not a feeling
On modern ERP and HCM UIs there is often no reliable DOM event that means “done” – and inside a remoted published app none you can trust from outside the glass. The practical signal is the bitmap:
- StartTimer when the user action happens – submit, click, or key.
- WaitForImage until a baseline of the ready state is visible: shell chrome, published-app home, transaction confirmation, report or export result.
- StopTimer when that image matches.
The recorded interval is click-to-ready for that step. Image recognition – and OCR when the ready state is text – is how you know the glass painted, without an agent inside SAP, Oracle, Workday, or the portal. That is the core of on-the-glass APM.
That pipeline is the same for shell, published app, key transaction, and handoff steps. Change the start action and the ready image. Keep the timer. Sister posts use the identical glass method for EHR and remoted desktops.
Stopwatch versus synthetic
A person with a stopwatch can time one published-app launch on a quiet morning. That is a demo, not a measurement program. A one-off cannot give a tail, run at cutover rush, hold concurrent consultant-like sessions while timing a Workday or SAP step, or attach a screenshot of the failed state. Means hide the damage until delivery is already saying “the app is slow.”
A synthetic does the same StartTimer → WaitForImage → StopTimer path as a real browser or remoted Workspace / Remote Desktop client, on a schedule or under load, with the same shell, published-app, transaction, and handoff-ready baselines – continuous on-the-glass monitoring, or a load/change test when it ramps virtual users.
If you only have a stopwatch, use it to write the acceptance line – then automate it. Example go-live language (schematic only – not a customer dataset or Deloitte SLA): sign-in to usable shell at p95 inside budget; published app ready at p95; key SAP / Oracle / Workday transaction inside budget at p95; fewer than 1 percent of runs hang or miss the ready image.
Continuous watch versus load test
On-the-glass is an idea, not a product SKU. Two jobs share the path:
- CitraTest VU load-tests capacity and change. Freeze the image, walk shell → published app → key transaction → handoff, ramp concurrent consultant-like users, stop at the written budget. When remoted, run storm and sustain separately. See CitraTest VU load testing.
- CitraTest APM watches production. The same steps, every N minutes, with alerts and screenshots when glass time slips. See CitraTest APM.
The lab answers how many good concurrent transformation workflows fit before click-to-ready breaks. The watch answers whether today’s published app and transaction steps are still inside the line. Do not use a load-test generator as your only production monitor. No agents inside the client’s SAP, Oracle, Workday, or portal tenant – each virtual user is another consultant or client browser (or remoted session) driving the UI like a person.
What this is not
- It is not a Deloitte SLA claim, engagement scorecard, or substitute for PMO program metrics. Keep RAID, milestones, and status for the program office.
- It is not a replacement for CDN, API, uptime, or browser RUM graphs. Keep those for the network and document path.
- It is not an HTTP soak of the login URL or a health endpoint. Keep that for the front door.
- It is not “we have full-stack APM, so the engagement apps are covered.” Published-app and ERP GUIs are pixels users wait on, not only traces.
- It is not a claim about Deloitte proprietary methods, unpublished client contracts, or SAP / Oracle / Workday internals – only delivered UI readiness on the glass.
- It is not a promise that last month’s number survives a UI redesign, new published-app image, browser update, or a move into Citrix / RDS / AVD. Re-time the glass when the image changes.
Take the interval users already wait
Deloitte-related response time – for the apps and desktops that matter in Deloitte-led work – is click-to-ready on the glass: shell, published app, key transaction, and handoff ready – not a green program dashboard or protocol tile. Time the steps that generate tickets at cutover and in day-to-day consulting delivery. When remoted, separate logon storm from density. Use a stopwatch only to write the line; use a synthetic to keep it: CitraTest VU under load or change, CitraTest APM on a continuous watch.
When you need that path without agents in the client tenant – real browser or remoted client, image and OCR, StartTimer to StopTimer for the apps that matter in Deloitte engagements – schedule a demo. Product pages: on-the-glass APM, CitraTest VU, and CitraTest APM.
Deloitte is a trademark of its respective owners. SAP, Oracle, Workday, Citrix, and related marks are trademarks of their respective owners. Tevron is not affiliated with Deloitte or those vendors. Names are used for identification only.